[jira] [Resolved] (CALCITE-1361) Remove entry from AvaticaConnection.flagMap when session closed
[ https://issues.apache.org/jira/browse/CALCITE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1361. -- Resolution: Fixed Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/fb6c24ad. > Remove entry from AvaticaConnection.flagMap when session closed > --- > > Key: CALCITE-1361 > URL: https://issues.apache.org/jira/browse/CALCITE-1361 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Labels: avatica > Fix For: avatica-1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1391) CRUD operations using Calcite for DRUID
[ https://issues.apache.org/jira/browse/CALCITE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15531009#comment-15531009 ] slim bouguerra edited comment on CALCITE-1391 at 9/28/16 11:22 PM: --- I think the scope of this request is not very clear. I will try to explain what druid is capable of hope that help to make the question more narrow. First let's keep in mind that druid is built around a very strong design hypothesis which is the immutability of the segments. By having a read only segments we can achieve huge speedup/caching. But this it does not mean that you can not insert/append or delete data. Assuming your are ingestion data via batch ingestion, let's start with the simple case which is delete data. Druid has the concept of load and drop rules for segments, hence to drop an entire segment all we need to do is to send a drop request to the coordinator. For instance in a reporting use case, usually you want to load the data for the last 3 months only, you can tell druid to only keep the segment within the last 3 months. Although if your use case is to delete one or N-rows from one segment that is not trivial. What you need to do is to send a new index task with the new data for that specific interval then druid will replace the old segment and by the new one. What this imply is that you won't really impact how fast or slow is the query. But druid will happily answer to the query using the old segment till the re-index task is done. For append/insert druid support delta batch ingestion. What this means you can trigger an index job and you tell druid that you want to append/insert this set of rows to this existing segment. What is the impact of this on the query. The answer is the same as above. Druid will answer to the query with the old data till the index map-reduce job is done. If you use case is realtime it is totally a different discussion. [~arupadhy] hope this make sense to you. Please feel free to explain more the use case you are targeting. was (Author: bslim): I think the scope of this request is not very clear. I will try to explain what druid is capable of hope that help to make the question more narrow. First let's keep in mind that druid is built around a very strong design hypothesis which is the immutability of the segments. By having a read only segments we can achieve huge speedup/caching. But this it does not mean that you can not insert/append or delete data. Assuming your are ingestion data via batch ingestion, let's start with the simple case which is delete data. Druid has the concept of load and drop rules for segments, hence to drop an entire segment all we need to do is to send a drop request to the coordinator. For instance in a reporting use case, usually you want to load the data for the last 3 months only, you can tell druid to only keep the segment within the last 3 months. Although if your use case is to delete one or N-rows from one segment that is not trivial. What you need to do is to send a new index task with the new data for that specific interval then druid will replace the old segment and by the new one. What this imply is that you won't really impact how fast or slow is the query. But druid will happily answer to the query using the old segment till the re-index task is done. For append/insert druid support delta batch ingestion. What his means you can trigger an index job and you tell druid that you want to append/insert this set of rows to this existing segment. What is the impact of this on the query. The answer is the same as above. Druid will answer to the query with the old data till the index map-reduce job is done. If you use case is realtime it is totally a different discussion. [~arupadhy] hope this make sense to you. Please feel free to explain more the use case you are targeting. > CRUD operations using Calcite for DRUID > --- > > Key: CALCITE-1391 > URL: https://issues.apache.org/jira/browse/CALCITE-1391 > Project: Calcite > Issue Type: Wish > Components: druid > Environment: Druid Production Environment >Reporter: Arvind >Assignee: Julian Hyde >Priority: Critical > > Hi Team, > I know that we are able to read data from druid using Calcite SQLLINE command > but I would like to know if we can insert, Update and delete segments in > DRUID using Calcite. We are using DRUID as a reporting platform and for us to > incrementally update, delete and append data we need these operations. As we > are dealing with huge volumes of data we depend on DRUID and very badly need > these Insert, Update and Delete. > Any help is much appreciated. > Thanks, > Arvind -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1391) CRUD operations using Calcite for DRUID
[ https://issues.apache.org/jira/browse/CALCITE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15531194#comment-15531194 ] Julian Hyde commented on CALCITE-1391: -- [~bslim], That makes a lot of sense. In short, in Calcite we should aim to expose Druid's existing functionality, mapping it to SQL in a straightforward way. If Calcite is trying to do too much work (e.g. if it needs a data structure or a protocol that Druid does not currently support) it will end badly. If the needed functionality is missing in Druid, let's take up that question on the Druid list. > CRUD operations using Calcite for DRUID > --- > > Key: CALCITE-1391 > URL: https://issues.apache.org/jira/browse/CALCITE-1391 > Project: Calcite > Issue Type: Wish > Components: druid > Environment: Druid Production Environment >Reporter: Arvind >Assignee: Julian Hyde >Priority: Critical > > Hi Team, > I know that we are able to read data from druid using Calcite SQLLINE command > but I would like to know if we can insert, Update and delete segments in > DRUID using Calcite. We are using DRUID as a reporting platform and for us to > incrementally update, delete and append data we need these operations. As we > are dealing with huge volumes of data we depend on DRUID and very badly need > these Insert, Update and Delete. > Any help is much appreciated. > Thanks, > Arvind -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1400) AggregatePullUpConstantsRule might adjust aggregation function parameters indices wrongly
[ https://issues.apache.org/jira/browse/CALCITE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15531182#comment-15531182 ] Julian Hyde commented on CALCITE-1400: -- +1 when you have a test that fails without the fix, passes with it. > AggregatePullUpConstantsRule might adjust aggregation function parameters > indices wrongly > - > > Key: CALCITE-1400 > URL: https://issues.apache.org/jira/browse/CALCITE-1400 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > > I explored a bit and I think this is a piece missing in CALCITE-1038. > Introducing a Project operator below as part of the rewriting was removed, > and thus, there is no need to adjust the indices of the aggregation function > parameters. However, the code is still there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1391) CRUD operations using Calcite for DRUID
[ https://issues.apache.org/jira/browse/CALCITE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15531009#comment-15531009 ] slim bouguerra commented on CALCITE-1391: - I think the scope of this request is not very clear. I will try to explain what druid is capable of hope that help to make the question more narrow. First let's keep in mind that druid is built around a very strong design hypothesis which is the immutability of the segments. By having a read only segments we can achieve huge speedup/caching. But this it does not mean that you can not insert/append or delete data. Assuming your are ingestion data via batch ingestion, let's start with the simple case which is delete data. Druid has the concept of load and drop rules for segments, hence to drop an entire segment all we need to do is to send a drop request to the coordinator. For instance in a reporting use case, usually you want to load the data for the last 3 months only, you can tell druid to only keep the segment within the last 3 months. Although if your use case is to delete one or N-rows from one segment that is not trivial. What you need to do is to send a new index task with the new data for that specific interval then druid will replace the old segment and by the new one. What this imply is that you won't really impact how fast or slow is the query. But druid will happily answer to the query using the old segment till the re-index task is done. For append/insert druid support delta batch ingestion. What his means you can trigger an index job and you tell druid that you want to append/insert this set of rows to this existing segment. What is the impact of this on the query. The answer is the same as above. Druid will answer to the query with the old data till the index map-reduce job is done. If you use case is realtime it is totally a different discussion. [~arupadhy] hope this make sense to you. Please feel free to explain more the use case you are targeting. > CRUD operations using Calcite for DRUID > --- > > Key: CALCITE-1391 > URL: https://issues.apache.org/jira/browse/CALCITE-1391 > Project: Calcite > Issue Type: Wish > Components: druid > Environment: Druid Production Environment >Reporter: Arvind >Assignee: Julian Hyde >Priority: Critical > > Hi Team, > I know that we are able to read data from druid using Calcite SQLLINE command > but I would like to know if we can insert, Update and delete segments in > DRUID using Calcite. We are using DRUID as a reporting platform and for us to > incrementally update, delete and append data we need these operations. As we > are dealing with huge volumes of data we depend on DRUID and very badly need > these Insert, Update and Delete. > Any help is much appreciated. > Thanks, > Arvind -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1391) CRUD operations using Calcite for DRUID
[ https://issues.apache.org/jira/browse/CALCITE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530935#comment-15530935 ] Julian Hyde commented on CALCITE-1391: -- If you were to implement INSERT, UPDATE and DELETE SQL commands against Druid, you would end up with a similar problem to the one Hive has: it is very inefficient to modify a single record in a (very large) segment. Hive's solution is [ACID|http://hortonworks.com/blog/adding-acid-to-apache-hive/], but it was a lot of work to merge deltas into every Hive read path. What kind of performance characteristics are you aiming for? If you're thinking of large, infrequent batch updates, then I think it could work. But frequent small updates would probably bring Druid to its knees. And I don't know whether Druid even supports updates and deletes. [~nishantbangarwa] and [~bslim], what do you think? > CRUD operations using Calcite for DRUID > --- > > Key: CALCITE-1391 > URL: https://issues.apache.org/jira/browse/CALCITE-1391 > Project: Calcite > Issue Type: Wish > Components: druid > Environment: Druid Production Environment >Reporter: Arvind >Assignee: Julian Hyde >Priority: Critical > > Hi Team, > I know that we are able to read data from druid using Calcite SQLLINE command > but I would like to know if we can insert, Update and delete segments in > DRUID using Calcite. We are using DRUID as a reporting platform and for us to > incrementally update, delete and append data we need these operations. As we > are dealing with huge volumes of data we depend on DRUID and very badly need > these Insert, Update and Delete. > Any help is much appreciated. > Thanks, > Arvind -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1399) SerializationConverter in HsqldbServer needs to be public
[
https://issues.apache.org/jira/browse/CALCITE-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1399.
-
Resolution: Fixed
Resolved in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=c9ec5c88dd46e2c49ec3137d835b086708fbc4d6
> SerializationConverter in HsqldbServer needs to be public
> -
>
> Key: CALCITE-1399
> URL: https://issues.apache.org/jira/browse/CALCITE-1399
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.9.0
>
>
> The standalone Avatica server built using HSQLDB has an {{IStringConverter}}
> implementation for controlling what Avatica serialization method (JSON or
> PROTOBUF) is used.
> But, this StringConverter class is private which breaks jcommander as it
> cannot access the class and instantiate it.
> Need to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1393) Exclude packages org.apache.calcite.benchmarks.generated, org.openjdk.jmh from javadoc
[ https://issues.apache.org/jira/browse/CALCITE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1393. -- Resolution: Fixed Fix Version/s: 1.10.0 Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/68395857. > Exclude packages org.apache.calcite.benchmarks.generated, org.openjdk.jmh > from javadoc > -- > > Key: CALCITE-1393 > URL: https://issues.apache.org/jira/browse/CALCITE-1393 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: 1.10.0 > > > Exclude packages org.apache.calcite.benchmarks.generated, org.openjdk.jmh > from javadoc. These are in the ubenchmark module (in main mode, not test > mode) but we don't want them to appear on the web site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1394) Using CoreMatchers.containsString causes javadoc errors
[
https://issues.apache.org/jira/browse/CALCITE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1394.
--
Resolution: Fixed
Fix Version/s: 1.10.0
avatica-1.9.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/514d262e. (The
peculiar fix version is because the commit contains a mixture of Calcite and
Avatica changes. That's not usually OK, but these are just issues with the
QA/release process, not functionality.)
> Using CoreMatchers.containsString causes javadoc errors
> ---
>
> Key: CALCITE-1394
> URL: https://issues.apache.org/jira/browse/CALCITE-1394
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: avatica-1.9.0, 1.10.0
>
>
> Under JDK 1.7, using the method {{CoreMatchers.containsString}} causes
> javadoc warnings, similar to https://github.com/junit-team/junit4/issues/872.
> The cause, I think, is that Avatica uses mockito and it bundles a different
> version of hamcrest. The solution is to use
> {{StringContains.containsString}}, which exists in an earlier version of
> hamcrest.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1399) SerializationConverter in HsqldbServer needs to be public
Josh Elser created CALCITE-1399:
---
Summary: SerializationConverter in HsqldbServer needs to be public
Key: CALCITE-1399
URL: https://issues.apache.org/jira/browse/CALCITE-1399
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.8.0
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Trivial
Fix For: avatica-1.9.0
The standalone Avatica server built using HSQLDB has an {{IStringConverter}}
implementation for controlling what Avatica serialization method (JSON or
PROTOBUF) is used.
But, this StringConverter class is private which breaks jcommander as it cannot
access the class and instantiate it.
Need to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1397) ClassCastException in FilterReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530752#comment-15530752
]
Julian Hyde commented on CALCITE-1397:
--
Need a test case.
It might be simpler if {{reduceNotNullableFilter}} accepted any {{RexNode}},
not just {{RexCall}}; it would no-op if the arg was not IS_NULL, IS_UNKNOWN,
IS_NOT_NULL. Then you can remove the casts and 'if' before you call it.
> ClassCastException in FilterReduceExpressionsRule
> -
>
> Key: CALCITE-1397
> URL: https://issues.apache.org/jira/browse/CALCITE-1397
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>
> L184 in ReduceExpressionsRule.
> {code}
> ...
> if (newConditionExp instanceof RexCall) {
> RexCall rexCall = (RexCall) newConditionExp;
> boolean reverse = rexCall.getKind() == SqlKind.NOT;
> if (reverse) {
> rexCall = (RexCall) rexCall.getOperands().get(0);
> }
> reduceNotNullableFilter(call, filter, rexCall, reverse);
> }
> ...
> {code}
> When we take the _NOT_ input, we do not consider that it might not be a
> RexCall, which may lead to the ClassCastException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1396) isDeterministic only explores top RexCall
[ https://issues.apache.org/jira/browse/CALCITE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530731#comment-15530731 ] Julian Hyde commented on CALCITE-1396: -- Any ideas how we could create a SQL test? Doesn't seem that it would be easy. +1 > isDeterministic only explores top RexCall > - > > Key: CALCITE-1396 > URL: https://issues.apache.org/jira/browse/CALCITE-1396 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1398) Change visibility of RelFieldTrimmer utility methods
[ https://issues.apache.org/jira/browse/CALCITE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530733#comment-15530733 ] Julian Hyde commented on CALCITE-1398: -- +1 > Change visibility of RelFieldTrimmer utility methods > > > Key: CALCITE-1398 > URL: https://issues.apache.org/jira/browse/CALCITE-1398 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > > The goal is that its subclasses can use them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530715#comment-15530715
]
Josh Elser commented on CALCITE-1110:
-
I'm also addressing this over in CALCITE-1224
https://github.com/apache/calcite/pull/282
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1398) Change visibility of RelFieldTrimmer utility methods
[ https://issues.apache.org/jira/browse/CALCITE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530702#comment-15530702 ] Jesus Camacho Rodriguez commented on CALCITE-1398: -- [~julianhyde], this one is straightforward; it will allow us to use the functions in Hive own RelFieldTrimmer implementation. https://github.com/apache/calcite/pull/288 Thanks > Change visibility of RelFieldTrimmer utility methods > > > Key: CALCITE-1398 > URL: https://issues.apache.org/jira/browse/CALCITE-1398 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > > The goal is that its subclasses can use them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1398) Change visibility of RelFieldTrimmer utility methods
Jesus Camacho Rodriguez created CALCITE-1398: Summary: Change visibility of RelFieldTrimmer utility methods Key: CALCITE-1398 URL: https://issues.apache.org/jira/browse/CALCITE-1398 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.9.0 Reporter: Jesus Camacho Rodriguez Assignee: Jesus Camacho Rodriguez The goal is that its subclasses can use them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1397) ClassCastException in FilterReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530212#comment-15530212
]
Jesus Camacho Rodriguez commented on CALCITE-1397:
--
[~julianhyde], could you take a look?
https://github.com/apache/calcite/pull/287
Thanks
> ClassCastException in FilterReduceExpressionsRule
> -
>
> Key: CALCITE-1397
> URL: https://issues.apache.org/jira/browse/CALCITE-1397
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>
> L184 in ReduceExpressionsRule.
> {code}
> ...
> if (newConditionExp instanceof RexCall) {
> RexCall rexCall = (RexCall) newConditionExp;
> boolean reverse = rexCall.getKind() == SqlKind.NOT;
> if (reverse) {
> rexCall = (RexCall) rexCall.getOperands().get(0);
> }
> reduceNotNullableFilter(call, filter, rexCall, reverse);
> }
> ...
> {code}
> When we take the _NOT_ input, we do not consider that it might not be a
> RexCall, which may lead to the ClassCastException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1396) isDeterministic only explores top RexCall
[ https://issues.apache.org/jira/browse/CALCITE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529942#comment-15529942 ] Jesus Camacho Rodriguez commented on CALCITE-1396: -- [~julianhyde], could you take a look? https://github.com/apache/calcite/pull/286 Thanks > isDeterministic only explores top RexCall > - > > Key: CALCITE-1396 > URL: https://issues.apache.org/jira/browse/CALCITE-1396 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1397) ClassCastException in FilterReduceExpressionsRule
Jesus Camacho Rodriguez created CALCITE-1397:
Summary: ClassCastException in FilterReduceExpressionsRule
Key: CALCITE-1397
URL: https://issues.apache.org/jira/browse/CALCITE-1397
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.9.0
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez
L184 in ReduceExpressionsRule.
{code}
...
if (newConditionExp instanceof RexCall) {
RexCall rexCall = (RexCall) newConditionExp;
boolean reverse = rexCall.getKind() == SqlKind.NOT;
if (reverse) {
rexCall = (RexCall) rexCall.getOperands().get(0);
}
reduceNotNullableFilter(call, filter, rexCall, reverse);
}
...
{code}
When we take the _NOT_ input, we do not consider that it might not be a
RexCall, which may lead to the ClassCastException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1392) Unable to specify time granularity for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529843#comment-15529843
]
Maciej Bryński commented on CALCITE-1392:
-
I didn't.
And I don't have "__time" column in my data source. I was sure that this is
meta column created by calcite itself.
Especially with this quote from calcite page
https://calcite.apache.org/docs/druid_adapter.html
{quote}
Simplifying the modelPermalink
If less metadata is provided in the model, the Druid adapter can discover it
automatically from Druid. Here is a schema equivalent to the previous one but
with dimensions, metrics and timestampColumn removed:
{quote}
> Unable to specify time granularity for Druid
>
>
> Key: CALCITE-1392
> URL: https://issues.apache.org/jira/browse/CALCITE-1392
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
>Reporter: Maciej Bryński
>Assignee: Julian Hyde
>
> Druid 0.9.1.1
> Calcite 1.9.0
> I'm trying to calculate count per day.
> What I'm doing wrong ?
> {code}
> !connect
> jdbc:calcite:schemaFactory=org.apache.calcite.adapter.druid.DruidSchemaFactory
> admin admin
> 0: jdbc:calcite:schemaFactory=org.apache.calc> !describe "table"
> +---+-++-+---+---+-+---+++--+-++---+--+
> | TABLE_CAT | TABLE_SCHEM | TABLE_NAME | COLUMN_NAME | DATA_TYPE | TYPE_NAME
> | COLUMN_SIZE | BUFFER_LENGTH | DECIMAL_DIGITS | NUM_PREC_RADIX | NULLABLE |
> REMARKS | COLUMN_DEF | SQL_DATA_TYPE | SQL_DATETIME_SUB |
> +---+-++-+---+---+-+---+++--+-++---+--+
> | | adhoc | table | __time | -5| BIGINT| -1
> | | null | 10 | 1|
> || | |
> |
> | | adhoc | table| count | -5| BIGINT|
> -1 | | null | 10 | 1|
> || |
> 0: jdbc:calcite:schemaFactory=org.apache.calc> select sum("count") from
> "table" group by floor("__time" to DAY);
> 2016-09-27 21:50:26,770 [main] ERROR -
> org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply 'FLOOR'
> to arguments of type 'FLOOR(, )'. Supported form(s):
> 'FLOOR()'
> 'FLOOR()'
> 'FLOOR( TO )'
> 'FLOOR( TO )'
> 'FLOOR( TO )'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1392) Unable to specify time granularity for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529843#comment-15529843
]
Maciej Bryński edited comment on CALCITE-1392 at 9/28/16 2:37 PM:
--
I didn't.
And I don't have "__time" column in my data source. I was sure that this is
meta column created by calcite itself. And it's type is not VARCHAR but BIGINT
Especially with this quote from calcite page
https://calcite.apache.org/docs/druid_adapter.html
{quote}
Simplifying the modelPermalink
If less metadata is provided in the model, the Druid adapter can discover it
automatically from Druid. Here is a schema equivalent to the previous one but
with dimensions, metrics and timestampColumn removed:
{quote}
was (Author: maver1ck):
I didn't.
And I don't have "__time" column in my data source. I was sure that this is
meta column created by calcite itself.
Especially with this quote from calcite page
https://calcite.apache.org/docs/druid_adapter.html
{quote}
Simplifying the modelPermalink
If less metadata is provided in the model, the Druid adapter can discover it
automatically from Druid. Here is a schema equivalent to the previous one but
with dimensions, metrics and timestampColumn removed:
{quote}
> Unable to specify time granularity for Druid
>
>
> Key: CALCITE-1392
> URL: https://issues.apache.org/jira/browse/CALCITE-1392
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
>Reporter: Maciej Bryński
>Assignee: Julian Hyde
>
> Druid 0.9.1.1
> Calcite 1.9.0
> I'm trying to calculate count per day.
> What I'm doing wrong ?
> {code}
> !connect
> jdbc:calcite:schemaFactory=org.apache.calcite.adapter.druid.DruidSchemaFactory
> admin admin
> 0: jdbc:calcite:schemaFactory=org.apache.calc> !describe "table"
> +---+-++-+---+---+-+---+++--+-++---+--+
> | TABLE_CAT | TABLE_SCHEM | TABLE_NAME | COLUMN_NAME | DATA_TYPE | TYPE_NAME
> | COLUMN_SIZE | BUFFER_LENGTH | DECIMAL_DIGITS | NUM_PREC_RADIX | NULLABLE |
> REMARKS | COLUMN_DEF | SQL_DATA_TYPE | SQL_DATETIME_SUB |
> +---+-++-+---+---+-+---+++--+-++---+--+
> | | adhoc | table | __time | -5| BIGINT| -1
> | | null | 10 | 1|
> || | |
> |
> | | adhoc | table| count | -5| BIGINT|
> -1 | | null | 10 | 1|
> || |
> 0: jdbc:calcite:schemaFactory=org.apache.calc> select sum("count") from
> "table" group by floor("__time" to DAY);
> 2016-09-27 21:50:26,770 [main] ERROR -
> org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply 'FLOOR'
> to arguments of type 'FLOOR(, )'. Supported form(s):
> 'FLOOR()'
> 'FLOOR()'
> 'FLOOR( TO )'
> 'FLOOR( TO )'
> 'FLOOR( TO )'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1395) Unable to get table of Druid
[
https://issues.apache.org/jira/browse/CALCITE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyle updated CALCITE-1395:
--
Description:
- If a table "bb" does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result, for another table "ab". If
normal get a null value。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
was:
- If a table "bb" does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result, for another table "ab",
normal get null。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
> Unable to get table of Druid
>
>
> Key: CALCITE-1395
> URL: https://issues.apache.org/jira/browse/CALCITE-1395
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
> Environment: Druid 0.9.1.1 + calcite 1.9.0
>Reporter: Lyle
>Assignee: Julian Hyde
>
> - If a table "bb" does not exist, execute the
> CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive =
> false and Lex.MYSQL_ANSI, Will get an unexpected result, for another table
> "ab". If normal get a null value。then throws a Exception:
> {code}
> java.sql.SQLException: Error while executing SQL "select count(*) as c from
> bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
> position (0) must be less than the number of elements that remained (0)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
>
>
[jira] [Updated] (CALCITE-1395) Unable to get table of Druid
[
https://issues.apache.org/jira/browse/CALCITE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyle updated CALCITE-1395:
--
Description:
- If a table "bb" does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result, for another table "ab",
normal get null。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
was:
- If a table "bb" does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result, for table "ab", normal get
null。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
> Unable to get table of Druid
>
>
> Key: CALCITE-1395
> URL: https://issues.apache.org/jira/browse/CALCITE-1395
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
> Environment: Druid 0.9.1.1 + calcite 1.9.0
>Reporter: Lyle
>Assignee: Julian Hyde
>
> - If a table "bb" does not exist, execute the
> CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive =
> false and Lex.MYSQL_ANSI, Will get an unexpected result, for another table
> "ab", normal get null。then throws a Exception:
> {code}
> java.sql.SQLException: Error while executing SQL "select count(*) as c from
> bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
> position (0) must be less than the number of elements that remained (0)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
>
> at
[jira] [Updated] (CALCITE-1395) Unable to get table of Druid
[
https://issues.apache.org/jira/browse/CALCITE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyle updated CALCITE-1395:
--
Description:
- If a table "bb" does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result, for table "ab", normal get
null。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
was:
- If a table does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive = false
and Lex.MYSQL_ANSI, Will get an unexpected result。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
> Unable to get table of Druid
>
>
> Key: CALCITE-1395
> URL: https://issues.apache.org/jira/browse/CALCITE-1395
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
> Environment: Druid 0.9.1.1 + calcite 1.9.0
>Reporter: Lyle
>Assignee: Julian Hyde
>
> - If a table "bb" does not exist, execute the
> CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive =
> false and Lex.MYSQL_ANSI, Will get an unexpected result, for table "ab",
> normal get null。then throws a Exception:
> {code}
> java.sql.SQLException: Error while executing SQL "select count(*) as c from
> bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
> position (0) must be less than the number of elements that remained (0)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
>
> at TestCalciteDruid.main(TestCalciteDruid.java:57)
> at
[jira] [Updated] (CALCITE-1395) Unable to get table of Druid
[
https://issues.apache.org/jira/browse/CALCITE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyle updated CALCITE-1395:
--
Description:
- If a table does not exist, execute the
CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive =
false, Will get an unexpected result。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
was:
- If a table does not exist, execute the
CachingCalciteSchema.getImplicitTable() and caseSensitive = false, Will get an
unexpected result。then throws a Exception:
{code}
java.sql.SQLException: Error while executing SQL "select count(*) as c from
bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
position (0) must be less than the number of elements that remained (0)
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
at TestCalciteDruid.main(TestCalciteDruid.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IndexOutOfBoundsException: position (0) must be less than the number
of elements that remained (0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
{code}
- Why should query table information by coordinater node, instead of the broker
node? coordinater node can not get table data of real-time node
> Unable to get table of Druid
>
>
> Key: CALCITE-1395
> URL: https://issues.apache.org/jira/browse/CALCITE-1395
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.9.0
> Environment: Druid 0.9.1.1 + calcite 1.9.0
>Reporter: Lyle
>Assignee: Julian Hyde
>
> - If a table does not exist, execute the
> CachingCalciteSchema.getImplicitTable() and the parameter caseSensitive =
> false, Will get an unexpected result。then throws a Exception:
> {code}
> java.sql.SQLException: Error while executing SQL "select count(*) as c from
> bb where __time = '1475043567605'": java.lang.IndexOutOfBoundsException:
> position (0) must be less than the number of elements that remained (0)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:208)
>
> at TestCalciteDruid.main(TestCalciteDruid.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
> at
>
