Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In aggregated tables, group by AGG_TIMESTAMP does not populate correct results #1591

Closed
Thidasala opened this issue Dec 19, 2019 · 3 comments · Fixed by #1593
Closed

In aggregated tables, group by AGG_TIMESTAMP does not populate correct results #1591

Thidasala opened this issue Dec 19, 2019 · 3 comments · Fixed by #1593

Comments

@Thidasala
Copy link

Thidasala commented Dec 19, 2019

Description:

Aggregation:

define aggregation ApiErroranalysisAgg
from Request
select apiName, apiVersion, apiMethod, apiResourceTemplate, responseCode, apiContext, sum(backendLatency) as backendLatency, sum(otherLatency) as otherLatency, count() as totalRequestCount, applicationName, label
group by responseCode, apiResourceTemplate
aggregate by requestTimestamp every seconds...years;

Query:

from ApiErroranalysisAgg 
on (apiName == \"EmployeeApi\" and responseCode>200) 
within 1560938182969L, 1576749384340L 
per \"hour\" 
select apiName, count(responseCode) as count, AGG_TIMESTAMP 
group by AGG_TIMESTAMP

Affected Siddhi Version:
5.0.0- 5.1.12

@niveathika
Copy link
Member

After the initial evaluation, it seems that the Siddhi Query selector does not recognise "group by AGG_TIMESTAMP"

@niveathika niveathika self-assigned this Dec 19, 2019
@niveathika
Copy link
Member

I was able to reproduce this only for Persistence table,
niveathika/siddhi-store-rdbms@1f1e4cd

Test case passes for in-memory tables: #1592

@niveathika
Copy link
Member

It seems the group by "AGG_TIMESTAMP" is removed when processing optimisation queries

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants