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.

Sign up for GitHub

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

Jump to bottom

SQL: grouping by double casted date value throws exception #37042

Closed
astefan opened this issue Dec 31, 2018 · 2 comments · Fixed by #39773
Closed

SQL: grouping by double casted date value throws exception #37042

astefan opened this issue Dec 31, 2018 · 2 comments · Fixed by #39773
Labels
:Analytics/SQL SQL querying >bug

Comments

@astefan
Copy link
Contributor

astefan commented Dec 31, 2018

Test data:

{"index":{}}
{"date2":"1977-04-20","date0":"2004-04-15","num4":10.85,"int0":1}

Query and thrown exception:

sql> SELECT CONVERT(CONVERT(date0, SQL_VARCHAR), SQL_DATE) FROM calcs GROUP BY 1;
Server error [Server encountered an error [Invalid date key returned: 2004-04-15T00:00:00.000Z]. [SqlIllegalArgumentException[Invalid date key returned: 2004-04-15T00:00:00.000Z]
        at org.elasticsearch.xpack.sql.execution.search.extractor.CompositeKeyExtractor.extract(CompositeKeyExtractor.java:100)
        at org.elasticsearch.xpack.sql.expression.gen.processor.BucketExtractorProcessor.process(BucketExtractorProcessor.java:50)
        at org.elasticsearch.xpack.sql.execution.search.extractor.ComputingExtractor.extract(ComputingExtractor.java:73)
        at org.elasticsearch.xpack.sql.execution.search.CompositeAggsRowSet.getColumn(CompositeAggsRowSet.java:64)
        at org.elasticsearch.xpack.sql.session.AbstractRowSet.column(AbstractRowSet.java:18)
        at org.elasticsearch.xpack.sql.session.RowView.forEachColumn(RowView.java:38)
        at org.elasticsearch.xpack.sql.plugin.TransportSqlQueryAction.lambda$createResponse$4(TransportSqlQueryAction.java:117)
        at org.elasticsearch.xpack.sql.session.RowSet.forEachRow(RowSet.java:32)
        at org.elasticsearch.xpack.sql.plugin.TransportSqlQueryAction.createResponse(TransportSqlQueryAction.java:115)
        at org.elasticsearch.xpack.sql.plugin.TransportSqlQueryAction.createResponse(TransportSqlQueryAction.java:110)
        at org.elasticsearch.xpack.sql.plugin.TransportSqlQueryAction.lambda$operation$0(TransportSqlQueryAction.java:83)
        at org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60)
        at org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60)
        at org.elasticsearch.xpack.sql.execution.search.Querier$CompositeActionListener.handleResponse(Querier.java:227)
        at org.elasticsearch.xpack.sql.execution.search.Querier$BaseActionListener.onResponse(Querier.java:408)
        at org.elasticsearch.xpack.sql.execution.search.Querier$BaseActionListener.onResponse(Querier.java:384)
        at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:64)
        at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:60)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.onResponse(AbstractSearchAsyncAction.java:313)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.onResponse(AbstractSearchAsyncAction.java:50)
        at org.elasticsearch.action.search.FetchSearchPhase$3.run(FetchSearchPhase.java:213)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.executePhase(AbstractSearchAsyncAction.java:160)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.executeNextPhase(AbstractSearchAsyncAction.java:153)
        at org.elasticsearch.action.search.ExpandSearchPhase.run(ExpandSearchPhase.java:120)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.executePhase(AbstractSearchAsyncAction.java:160)
        at org.elasticsearch.action.search.AbstractSearchAsyncAction.executeNextPhase(AbstractSearchAsyncAction.java:153)
        at org.elasticsearch.action.search.FetchSearchPhase.moveToNextPhase(FetchSearchPhase.java:206)
        at org.elasticsearch.action.search.FetchSearchPhase.lambda$innerRun$2(FetchSearchPhase.java:104)
        at org.elasticsearch.action.search.FetchSearchPhase.innerRun(FetchSearchPhase.java:110)
        at org.elasticsearch.action.search.FetchSearchPhase.access$000(FetchSearchPhase.java:44)
        at org.elasticsearch.action.search.FetchSearchPhase$1.doRun(FetchSearchPhase.java:86)
        at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:759)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
        at org.elasticsearch.common.util.concurrent.TimedRunnable.doRun(TimedRunnable.java:41)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)
]]
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@astefan astefan mentioned this issue Dec 31, 2018
Closed
@imotov
Copy link
Contributor

imotov commented Mar 6, 2019

The original repro no longer reproduces the issue because it was partially fixed by #37693. However, I stumbled upon another issue that still triggers the same error in the same place. I was able to reproduce it with this:

SELECT CONVERT(CONVERT(date0, SQL_VARCHAR), SQL_TIMESTAMP) FROM calcs GROUP BY 1;

@imotov imotov mentioned this issue Mar 6, 2019
Merged
imotov added a commit to imotov/elasticsearch that referenced this issue Mar 7, 2019
@imotov
SQL: values in datetime script aggs should be treated as long
1721716 
When a query is translated into script terms agg where key has a date
type, it should generate a terms agg with value_type long instead of
date, otherwise the key gets formatted as a string, which confuses
hit extractor.

Fixes elastic#37042
imotov added a commit that referenced this issue Mar 8, 2019
@imotov
SQL: values in datetime script aggs should be treated as long (#39773)
e51665b 
When a query is translated into script terms agg where key has a date
type, it should generate a terms agg with value_type long instead of
date, otherwise the key gets formatted as a string, which confuses
hit extractor.

Fixes #37042
imotov added a commit that referenced this issue Mar 11, 2019
@imotov
SQL: values in datetime script aggs should be treated as long (#39773)
2f47e3d 
When a query is translated into script terms agg where key has a date
type, it should generate a terms agg with value_type long instead of
date, otherwise the key gets formatted as a string, which confuses
hit extractor.

Fixes #37042
imotov added a commit that referenced this issue Mar 11, 2019
@imotov
SQL: values in datetime script aggs should be treated as long (#39773)
6cf980f 
When a query is translated into script terms agg where key has a date
type, it should generate a terms agg with value_type long instead of
date, otherwise the key gets formatted as a string, which confuses
hit extractor.

Fixes #37042
imotov added a commit that referenced this issue Mar 12, 2019
@imotov
SQL: values in datetime script aggs should be treated as long (#39773)
fb31f9a 
When a query is translated into script terms agg where key has a date
type, it should generate a terms agg with value_type long instead of
date, otherwise the key gets formatted as a string, which confuses
hit extractor.

Fixes #37042
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
:Analytics/SQL SQL querying >bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

SQL: values in datetime script aggs should be treated as long imotov/elasticsearch
3 participants
@imotov @astefan @elasticmachine