[jira] [Created] (CALCITE-1272) Can't use tables created in JsonMapSchema in JsonSchema materializations
Michael Mior created CALCITE-1272:
-
Summary: Can't use tables created in JsonMapSchema in JsonSchema
materializations
Key: CALCITE-1272
URL: https://issues.apache.org/jira/browse/CALCITE-1272
Project: Calcite
Issue Type: Bug
Reporter: Michael Mior
Assignee: Julian Hyde
Currently since {{JsonMapSchema}} is a subclass of {{JsonSchema}} it calls
{{super}} first in its {{visitChildren}} method. {{visitChildren}} accepts any
materializations before any custom tables have a chance to be populated. This
means that these tables can't be used in materializations. Not sure what the
best way to fix this is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1273) Outdated documentation in TranslatableTable
[
https://issues.apache.org/jira/browse/CALCITE-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315988#comment-15315988
]
Michael Mior commented on CALCITE-1273:
---
What's the status of the TPC-DS adapter? I see that the tests for it still
mention {{EnumerableTableAccessRel}} so I assume no one runs these tests
anymore (or they would have failed).
> Outdated documentation in TranslatableTable
> ---
>
> Key: CALCITE-1273
> URL: https://issues.apache.org/jira/browse/CALCITE-1273
> Project: Calcite
> Issue Type: Bug
>Reporter: Michael Mior
>Assignee: Julian Hyde
>
> {{TranslatableTable}} mentions {{EnumerableTableAccessRel}} which no longer
> exists. I'm not sure how the situation has changed now but it would be nice
> if the documentation could be updated to reflect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1273) Outdated documentation in TranslatableTable
[
https://issues.apache.org/jira/browse/CALCITE-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15316454#comment-15316454
]
Michael Mior commented on CALCITE-1273:
---
Okay, great. I'll leave this one to you then :)
> Outdated documentation in TranslatableTable
> ---
>
> Key: CALCITE-1273
> URL: https://issues.apache.org/jira/browse/CALCITE-1273
> Project: Calcite
> Issue Type: Bug
>Reporter: Michael Mior
>Assignee: Julian Hyde
>
> {{TranslatableTable}} mentions {{EnumerableTableAccessRel}} which no longer
> exists. I'm not sure how the situation has changed now but it would be nice
> if the documentation could be updated to reflect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1273) Outadated documentation in TranslatableTable
Michael Mior created CALCITE-1273:
-
Summary: Outadated documentation in TranslatableTable
Key: CALCITE-1273
URL: https://issues.apache.org/jira/browse/CALCITE-1273
Project: Calcite
Issue Type: Bug
Reporter: Michael Mior
Assignee: Julian Hyde
{{TranslatableTable}} mentions {{EnumerableTableAccessRel}} which no longer
exists. I'm not sure how the situation has changed now but it would be nice if
the documentation could be updated to reflect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1253) Create Elasticsearch adapter for Calcite
[ https://issues.apache.org/jira/browse/CALCITE-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15304345#comment-15304345 ] Michael Mior commented on CALCITE-1253: --- AFAIK, the [PR|https://github.com/vlsi/calcite-test-dataset/pull/11] for test dataset is ready to go. (Any outstanding issues [~vlsi]?) I think it would be nice to have that merged first if possible so integration tests are ready to be run but I'm +1 on committing either way. > Create Elasticsearch adapter for Calcite > > > Key: CALCITE-1253 > URL: https://issues.apache.org/jira/browse/CALCITE-1253 > Project: Calcite > Issue Type: New Feature >Reporter: Subhobrata Dey >Assignee: Julian Hyde > > This JIRA ticket is created to propose the addition of the new Elasticsearch > adapter for Calcite. > The adapter exposes a SQL interface to elasticsearch which includes > projection, filtering, sort, fetch, offset queries. > I have provided a couple of PRs, the first one is for the elasticsearch > adapter & the second one is for enhancing the Vagrantfile for loading test > data required for running the Junits. > Currently, the support for aggregates is not provided. The work on it is in > progress. > Kindly evaluate my contribution & please consider it as an addition to the > calcite project. > Following PRs are provided: > https://github.com/apache/calcite/pull/236 > https://github.com/vlsi/calcite-test-dataset/pull/10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1298) Deprecate little-used Util functions
[
https://issues.apache.org/jira/browse/CALCITE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1298:
--
Summary: Deprecate little-used Util functions (was: Consider removing
Util.toString)
> Deprecate little-used Util functions
>
>
> Key: CALCITE-1298
> URL: https://issues.apache.org/jira/browse/CALCITE-1298
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Julian Hyde
>Priority: Minor
>
> {{Util.toString}} seems unnecessary in light of
> {{com.google.common.base.Joiner}}. There are ~16 total usages of this across
> the entire code base. One inside {{SubstitutionVisitor}} and the rest
> scattered around the Mongo, Cassandra, and Elasticsearch adapters. If there
> are no objections, I'll remove this and replace with {{Joiner}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1298) Deprecate little-used Util functions
[
https://issues.apache.org/jira/browse/CALCITE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15338168#comment-15338168
]
Michael Mior commented on CALCITE-1298:
---
Deprecated all but {{Util.isNullOrEmpty}} so far. In the three cases I think
it's reasonable to use {{value && value.length() > 0}}. As for
{{Util.sepList}}, it did have special cases for 0 and 1 elements which could
make things a bit more efficient but presumably it won't be be a huge source of
overhead.
> Deprecate little-used Util functions
>
>
> Key: CALCITE-1298
> URL: https://issues.apache.org/jira/browse/CALCITE-1298
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Julian Hyde
>Priority: Minor
>
> {{Util.toString}} seems unnecessary in light of
> {{com.google.common.base.Joiner}}. There are ~16 total usages of this across
> the entire code base. One inside {{SubstitutionVisitor}} and the rest
> scattered around the Mongo, Cassandra, and Elasticsearch adapters. If there
> are no objections, I'll remove this and replace with {{Joiner}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1298) Consider removing Util.toString
Michael Mior created CALCITE-1298:
-
Summary: Consider removing Util.toString
Key: CALCITE-1298
URL: https://issues.apache.org/jira/browse/CALCITE-1298
Project: Calcite
Issue Type: Improvement
Reporter: Michael Mior
Assignee: Julian Hyde
Priority: Minor
{{Util.toString}} seems unnecessary in light of
{{com.google.common.base.Joiner}}. There are ~16 total usages of this across
the entire code base. One inside {{SubstitutionVisitor}} and the rest scattered
around the Mongo, Cassandra, and Elasticsearch adapters. If there are no
objections, I'll remove this and replace with {{Joiner}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1080: -- Description: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling * Exploit native aggregation was: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140248#comment-15140248 ] Michael Mior commented on CALCITE-1080: --- In terms of help, I wouldn't mind some code review of what I have so far to see if the approach I'm taking makes sense. In the mean time, I think I'll focus on getting a good set of tests going since I agree it would make it easier for others to start playing with it. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1080: -- Description: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling * Exploit native aggregation * Documentation * Correct literal formatting (e.g. dates, timestamps, etc.) was: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling * Exploit native aggregation > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1099) Upgrade Cassandra driver to support 3.0 server
[ https://issues.apache.org/jira/browse/CALCITE-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163814#comment-15163814 ] Michael Mior commented on CALCITE-1099: --- Fair point that it's unlikely someone will need support for both Hive and Cassandra at the same time. The ideal solution seems to be to request version 15.0, but fall back to 14.0.1 if a dependency on it is given elsewhere in the dependency tree. The easiest way would probably be to make this choice explicit and have a separate profile, but it would be nice to avoid having to do that. > Upgrade Cassandra driver to support 3.0 server > -- > > Key: CALCITE-1099 > URL: https://issues.apache.org/jira/browse/CALCITE-1099 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > Labels: cassandra > > The current version of the Java driver used in the Cassandra adapter does not > support Cassandra server 3.0.x. Upgrading is a fairly straightforward > process. However, the new version of the driver depends on Guava 15.0 and it > looks like Calcite is currently pinned at 14.0.1 for compatibility with Hive > (it looks like Spark is stuck on this version as well). Any thoughts on how > to resolve this conflict? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1104) Materialized view support for Cassandra adapter
Michael Mior created CALCITE-1104: - Summary: Materialized view support for Cassandra adapter Key: CALCITE-1104 URL: https://issues.apache.org/jira/browse/CALCITE-1104 Project: Calcite Issue Type: Improvement Reporter: Michael Mior Assignee: Julian Hyde Priority: Minor I managed to get support for a subset of Cassandra [materialized views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. ( Thanks owed to some hints from [~maryannxue]!) The one thing I noticed so far which is not supported is UUID literals in the WHERE clauses in the Cassandra view definition. However, I don't think that's a common use case. The adapter will log a warning if it encounters a view that can't be processed. At the very least, the view will be exposed as a table to Calcite (it wasn't in the previous version of the adapter). As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], there is probably a better way to hook in and add these views. I thought I would still put this up for now. I'd still like to add some tests before considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15170301#comment-15170301 ] Michael Mior commented on CALCITE-1104: --- [PR on GitHub|https://github.com/apache/calcite/pull/200] for review. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1099) Upgrade Cassandra driver to support 3.0 server
Michael Mior created CALCITE-1099: - Summary: Upgrade Cassandra driver to support 3.0 server Key: CALCITE-1099 URL: https://issues.apache.org/jira/browse/CALCITE-1099 Project: Calcite Issue Type: Improvement Reporter: Michael Mior Assignee: Julian Hyde Priority: Minor The current version of the Java driver used in the Cassandra adapter does not support Cassandra server 3.0.x. Upgrading is a fairly straightforward process. However, the new version of the driver depends on Guava 15.0 and it looks like Calcite is currently pinned at 14.0.1 for compatibility with Hive (it looks like Spark is stuck on this version as well). Any thoughts on how to resolve this conflict? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-917) Add support for EXPLAIN PLAN AS JSON
[ https://issues.apache.org/jira/browse/CALCITE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107537#comment-15107537 ] Michael Mior commented on CALCITE-917: -- I thought this would be a fun one to try to tackle to start getting familiar with Calcite. So far I managed to extend the grammar to include "AS JSON" and I'm just working on actually dumping the JSON output. WIP at https://github.com/michaelmior/calcite/tree/917-explain-json > Add support for EXPLAIN PLAN AS JSON > > > Key: CALCITE-917 > URL: https://issues.apache.org/jira/browse/CALCITE-917 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jacques Nadeau > Labels: newbie > > Explain plan currently supports outputting text and xml. Let's add an option > to explain plan "AS JSON". Drill will definitely plug into this. Other > systems could as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149116#comment-15149116 ] Michael Mior commented on CALCITE-1080: --- Will do. I realized I haven't made sure that the Splunk provisioning is still working so I'd like to do that first to avoid breaking anything. I'll update once I have a PR ready for the test VM. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149201#comment-15149201 ] Michael Mior commented on CALCITE-1080: --- Pull request [here|https://github.com/vlsi/calcite-test-dataset/pull/5]. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149249#comment-15149249 ] Michael Mior commented on CALCITE-1080: --- As an aside, what's the full command line to just run JdbcTest? I'm not too familiar with Maven so I've just been running the whole test suite. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152789#comment-15152789 ] Michael Mior commented on CALCITE-1080: --- Great, thanks :) > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152965#comment-15152965 ] Michael Mior commented on CALCITE-1080: --- Edited the adapter documentation and squashed the commits. PR is updated on GitHub. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation > * Documentation > * Correct literal formatting (e.g. dates, timestamps, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173215#comment-15173215 ] Michael Mior commented on CALCITE-1104: --- Yes. I haven't been pushing on this since it's blocked on the Guava upgrade anyway. I should be able to make some movement later this week. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1099) Upgrade Cassandra driver to support 3.0 server
[ https://issues.apache.org/jira/browse/CALCITE-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-1099. --- Resolution: Fixed > Upgrade Cassandra driver to support 3.0 server > -- > > Key: CALCITE-1099 > URL: https://issues.apache.org/jira/browse/CALCITE-1099 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > Labels: cassandra > > The current version of the Java driver used in the Cassandra adapter does not > support Cassandra server 3.0.x. Upgrading is a fairly straightforward > process. However, the new version of the driver depends on Guava 15.0 and it > looks like Calcite is currently pinned at 14.0.1 for compatibility with Hive > (it looks like Spark is stuck on this version as well). Any thoughts on how > to resolve this conflict? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187938#comment-15187938 ] Michael Mior commented on CALCITE-1104: --- PR has been merged. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1130) Add unary operator support for IS_NULL and IS_NOT_NULL to RexImplicationChecker
[ https://issues.apache.org/jira/browse/CALCITE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185086#comment-15185086 ] Michael Mior commented on CALCITE-1130: --- Yup! This seems to fix things. I still have a couple other issues to sort through with [CALCITE-1104|https://issues.apache.org/jira/browse/CALCITE-1104], but this seems to work as expected. Thanks [~amargoor]! > Add unary operator support for IS_NULL and IS_NOT_NULL to > RexImplicationChecker > --- > > Key: CALCITE-1130 > URL: https://issues.apache.org/jira/browse/CALCITE-1130 > Project: Calcite > Issue Type: Improvement >Reporter: Amogh Margoor >Assignee: Julian Hyde > > Currently we support only SQL Comparison operators (SqlKind.COMPARE) for > checking if one predicate implies another using RexImplicationChecker. > We would like to extend it for couple of Unary operators based on user > request ( CALCITE-1104): IS_NULL and IS_NOT_NULL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181919#comment-15181919 ] Michael Mior commented on CALCITE-1104: --- While trying to put a reasonable set of tests together, I encountered the following warning that prevents Calcite from using a materialized view which includes "IS NOT NULL" and a query which tests the same column against a string constant [main] WARN - Support for checking =(CAST($2):CHAR(3) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", 'fOGctyIDES') => IS NOT NULL($2) is not there Any ideas how this can be resolved? It seems like deciding that a non-null string constant is not null should be trivial but I'm sure I'm missing some complexities. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182600#comment-15182600 ] Michael Mior commented on CALCITE-1104: --- Awesome, thanks! Let me know if there's anything I can do to help. This happens to be particularly relevant here because Cassandra requires that materialized views be defined by a query which cannot produce NULL values for the primary keys. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181511#comment-15181511 ] Michael Mior commented on CALCITE-1104: --- Confirmed that this allows the upgrade to the new version of the Cassandra driver. I'll try to add those tests in tomorrow. Will probably require a PR to add a materialized view to the sample dataset in the VM. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1104) Materialized view support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185654#comment-15185654 ] Michael Mior commented on CALCITE-1104: --- Now that 1130 is cleared up, this is almost good to go. I have a [PR|https://github.com/vlsi/calcite-test-dataset/pull/6] in for the test VM to upgrade and I still just need to write a couple unit tests. > Materialized view support for Cassandra adapter > --- > > Key: CALCITE-1104 > URL: https://issues.apache.org/jira/browse/CALCITE-1104 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Minor > > I managed to get support for a subset of Cassandra [materialized > views|https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views]. > ( Thanks owed to some hints from [~maryannxue]!) > The one thing I noticed so far which is not supported is UUID literals in the > WHERE clauses in the Cassandra view definition. However, I don't think that's > a common use case. The adapter will log a warning if it encounters a view > that can't be processed. At the very least, the view will be exposed as a > table to Calcite (it wasn't in the previous version of the adapter). > As per [CALCITE-1101|https://issues.apache.org/jira/browse/CALCITE-1101], > there is probably a better way to hook in and add these views. I thought I > would still put this up for now. I'd still like to add some tests before > considering this viable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15255126#comment-15255126
]
Michael Mior commented on CALCITE-1212:
---
If you get the chance, it would be great if you could try out [this
branch|https://github.com/michaelmior/calcite/tree/1212-project-npe] and see if
it fixes your problem.
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15254998#comment-15254998
]
Michael Mior commented on CALCITE-1212:
---
The main issue is that the adapter currently isn't smart enough to know that it
can't push down the {{bar}} column. I'm working on a fix and I should be able
to have something out this weekend.
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257302#comment-15257302
]
Michael Mior commented on CALCITE-1212:
---
Fixed in
[6baa9c4|https://github.com/apache/calcite/commit/6baa9c4bed1100012ebf4ef9547cbb077f2edaaf].
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */
[jira] [Resolved] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-1212.
---
Resolution: Fixed
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return v1[4] == null ? (String) null : v1[4].toString();
> /* 48 */ }
> /* 49 */ public Object
[jira] [Assigned] (CALCITE-1211) limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
[
https://issues.apache.org/jira/browse/CALCITE-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior reassigned CALCITE-1211:
-
Assignee: Michael Mior (was: Julian Hyde)
> limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
> ---
>
> Key: CALCITE-1211
> URL: https://issues.apache.org/jira/browse/CALCITE-1211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> I copied the testProject query because I was noticing a {{EnumerableLimit}}
> showing up on explains when a limit was higher than `1`. So I narrowed it
> down to 7, anything above 7 and the plan looks like this
> {code}
> Plan after physical tweaks: EnumerableLimit(fetch=[8]): rowcount = 8.0,
> cumulative cost = {112.5 rows, 122.0 cpu, 0.0 io}, id = 2083
> CassandraToEnumerableConverter: rowcount = 15.0, cumulative cost = {104.5
> rows, 114.0 cpu, 0.0 io}, id = 2081
> CassandraProject(tweet_id=[$2]): rowcount = 15.0, cumulative cost =
> {103.0 rows, 112.5 cpu, 0.0 io}, id = 2079
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2077
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1915
> {code}
> anything {{7}} or below looks like this
> {code}
> CassandraToEnumerableConverter: rowcount = 7.0, cumulative cost =
> {111.07282262603232 rows, 112.75 cpu, 0.0 io}, id = 2257
> CassandraProject(tweet_id=[$2]): rowcount = 7.0, cumulative cost =
> {110.37282262603232 rows, 112.05 cpu, 0.0 io}, id = 2255
> CassandraSort(fetch=[7]): rowcount = 7.0, cumulative cost =
> {109.67282262603231 rows, 111.35 cpu, 0.0 io}, id = 2253
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2251
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 2089
> {code}
> If I wanted to change that would I alter the cost of the sort rule?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1210) Cassandra uuid filtering does not work
[
https://issues.apache.org/jira/browse/CALCITE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior reassigned CALCITE-1210:
-
Assignee: Michael Mior (was: Julian Hyde)
> Cassandra uuid filtering does not work
> --
>
> Key: CALCITE-1210
> URL: https://issues.apache.org/jira/browse/CALCITE-1210
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> It looks like the syntax for sending a uuid to cassandra is something like
> this
> {code}
> select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e
> {code}
> Which is a bare identifier, unquoted. So any filtering based on uuid's
> doesn't work. You get something like this:
> {code}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
> STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type
> uuid`
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1210) Cassandra uuid filtering does not work
[
https://issues.apache.org/jira/browse/CALCITE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253922#comment-15253922
]
Michael Mior commented on CALCITE-1210:
---
Fixed in
[c07f33a|https://github.com/apache/calcite/commit/c07f33ae62fd7b3c91713e3f7a038031fb7db5b9].
> Cassandra uuid filtering does not work
> --
>
> Key: CALCITE-1210
> URL: https://issues.apache.org/jira/browse/CALCITE-1210
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> It looks like the syntax for sending a uuid to cassandra is something like
> this
> {code}
> select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e
> {code}
> Which is a bare identifier, unquoted. So any filtering based on uuid's
> doesn't work. You get something like this:
> {code}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
> STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type
> uuid`
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior reassigned CALCITE-1212:
-
Assignee: Michael Mior (was: Julian Hyde)
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return v1[4] == null ? (String) null : v1[4].toString();
> /* 48 */ }
> /* 49
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253989#comment-15253989
]
Michael Mior commented on CALCITE-1212:
---
Thanks for sharing! This looks like enough info for me to start digging into
this.
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return v1[4]
[jira] [Resolved] (CALCITE-1210) Cassandra uuid filtering does not work
[
https://issues.apache.org/jira/browse/CALCITE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-1210.
---
Resolution: Fixed
> Cassandra uuid filtering does not work
> --
>
> Key: CALCITE-1210
> URL: https://issues.apache.org/jira/browse/CALCITE-1210
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> It looks like the syntax for sending a uuid to cassandra is something like
> this
> {code}
> select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e
> {code}
> Which is a bare identifier, unquoted. So any filtering based on uuid's
> doesn't work. You get something like this:
> {code}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
> STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type
> uuid`
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1211) limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
[
https://issues.apache.org/jira/browse/CALCITE-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253983#comment-15253983
]
Michael Mior commented on CALCITE-1211:
---
Thanks for the suggestion [~julianhyde]. Fixed in
[62f9aba|https://github.com/apache/calcite/commit/62f9abae4e0c79b02d4a46b4a6aa40aebc6418f9].
> limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
> ---
>
> Key: CALCITE-1211
> URL: https://issues.apache.org/jira/browse/CALCITE-1211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> I copied the testProject query because I was noticing a {{EnumerableLimit}}
> showing up on explains when a limit was higher than `1`. So I narrowed it
> down to 7, anything above 7 and the plan looks like this
> {code}
> Plan after physical tweaks: EnumerableLimit(fetch=[8]): rowcount = 8.0,
> cumulative cost = {112.5 rows, 122.0 cpu, 0.0 io}, id = 2083
> CassandraToEnumerableConverter: rowcount = 15.0, cumulative cost = {104.5
> rows, 114.0 cpu, 0.0 io}, id = 2081
> CassandraProject(tweet_id=[$2]): rowcount = 15.0, cumulative cost =
> {103.0 rows, 112.5 cpu, 0.0 io}, id = 2079
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2077
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1915
> {code}
> anything {{7}} or below looks like this
> {code}
> CassandraToEnumerableConverter: rowcount = 7.0, cumulative cost =
> {111.07282262603232 rows, 112.75 cpu, 0.0 io}, id = 2257
> CassandraProject(tweet_id=[$2]): rowcount = 7.0, cumulative cost =
> {110.37282262603232 rows, 112.05 cpu, 0.0 io}, id = 2255
> CassandraSort(fetch=[7]): rowcount = 7.0, cumulative cost =
> {109.67282262603231 rows, 111.35 cpu, 0.0 io}, id = 2253
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2251
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 2089
> {code}
> If I wanted to change that would I alter the cost of the sort rule?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257455#comment-15257455
]
Michael Mior commented on CALCITE-1212:
---
Looks like it did break the build indeed. This is odd since I didn't get this
issue locally. Easy fix though. Will push shortly.
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String
[jira] [Updated] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1212:
--
Affects Version/s: 1.7.0
Component/s: cassandra
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return v1[4]
[jira] [Commented] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257459#comment-15257459
]
Michael Mior commented on CALCITE-1212:
---
Should be resolved by
[CALCITE-1215|https://issues.apache.org/jira/browse/CALCITE-1215].
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return
[jira] [Updated] (CALCITE-1211) limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
[
https://issues.apache.org/jira/browse/CALCITE-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1211:
--
Component/s: cassandra
> limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
> ---
>
> Key: CALCITE-1211
> URL: https://issues.apache.org/jira/browse/CALCITE-1211
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
>
> I copied the testProject query because I was noticing a {{EnumerableLimit}}
> showing up on explains when a limit was higher than `1`. So I narrowed it
> down to 7, anything above 7 and the plan looks like this
> {code}
> Plan after physical tweaks: EnumerableLimit(fetch=[8]): rowcount = 8.0,
> cumulative cost = {112.5 rows, 122.0 cpu, 0.0 io}, id = 2083
> CassandraToEnumerableConverter: rowcount = 15.0, cumulative cost = {104.5
> rows, 114.0 cpu, 0.0 io}, id = 2081
> CassandraProject(tweet_id=[$2]): rowcount = 15.0, cumulative cost =
> {103.0 rows, 112.5 cpu, 0.0 io}, id = 2079
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2077
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1915
> {code}
> anything {{7}} or below looks like this
> {code}
> CassandraToEnumerableConverter: rowcount = 7.0, cumulative cost =
> {111.07282262603232 rows, 112.75 cpu, 0.0 io}, id = 2257
> CassandraProject(tweet_id=[$2]): rowcount = 7.0, cumulative cost =
> {110.37282262603232 rows, 112.05 cpu, 0.0 io}, id = 2255
> CassandraSort(fetch=[7]): rowcount = 7.0, cumulative cost =
> {109.67282262603231 rows, 111.35 cpu, 0.0 io}, id = 2253
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2251
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 2089
> {code}
> If I wanted to change that would I alter the cost of the sort rule?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1215) Missing method override in CassandraTable
[ https://issues.apache.org/jira/browse/CALCITE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-1215: - Assignee: Michael Mior > Missing method override in CassandraTable > - > > Key: CALCITE-1215 > URL: https://issues.apache.org/jira/browse/CALCITE-1215 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) > on project calcite-cassandra: Compilation failure > [ERROR] > /Users/jni/work/optiq/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraTable.java:[151,41] > is not > abstract and does not override abstract method remove() in java.util.Iterator > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :calcite-cassandra -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1215) Missing method override in CassandraTable
[ https://issues.apache.org/jira/browse/CALCITE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-1215. --- Resolution: Fixed > Missing method override in CassandraTable > - > > Key: CALCITE-1215 > URL: https://issues.apache.org/jira/browse/CALCITE-1215 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) > on project calcite-cassandra: Compilation failure > [ERROR] > /Users/jni/work/optiq/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraTable.java:[151,41] > is not > abstract and does not override abstract method remove() in java.util.Iterator > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :calcite-cassandra -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1215) Missing method override in CassandraTable
[
https://issues.apache.org/jira/browse/CALCITE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257466#comment-15257466
]
Michael Mior commented on CALCITE-1215:
---
FYI, this slipped passed me because I'm developing on JDK 1.8 which has a
default implementation of {{remove}} that isn't available in 1.7.
> Missing method override in CassandraTable
> -
>
> Key: CALCITE-1215
> URL: https://issues.apache.org/jira/browse/CALCITE-1215
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Reporter: Michael Mior
>Assignee: Michael Mior
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile)
> on project calcite-cassandra: Compilation failure
> [ERROR]
> /Users/jni/work/optiq/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraTable.java:[151,41]
> is not
> abstract and does not override abstract method remove() in java.util.Iterator
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :calcite-cassandra
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[ https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15292781#comment-15292781 ] Michael Mior commented on CALCITE-1235: --- Sounds good. I don't think this is ideal, but it's well-tested and it works and I think not too ugly so I'll commit for now and think about how this can be improved in the longer term. Thanks! > Push down LIMIT in unfiltered Cassandra queries > --- > > Key: CALCITE-1235 > URL: https://issues.apache.org/jira/browse/CALCITE-1235 > Project: Calcite > Issue Type: Improvement > Components: cassandra >Affects Versions: 1.7.0 >Reporter: Michael Mior >Assignee: Michael Mior > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[ https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15292797#comment-15292797 ] Michael Mior commented on CALCITE-1235: --- Fixed in [4c89dce|https://github.com/apache/calcite/commit/4c89dce303f8760e10bde3ab2b387780ae059e31]. > Push down LIMIT in unfiltered Cassandra queries > --- > > Key: CALCITE-1235 > URL: https://issues.apache.org/jira/browse/CALCITE-1235 > Project: Calcite > Issue Type: Improvement > Components: cassandra >Affects Versions: 1.7.0 >Reporter: Michael Mior >Assignee: Michael Mior > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[ https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-1235. --- Resolution: Fixed Fix Version/s: 1.8.0 > Push down LIMIT in unfiltered Cassandra queries > --- > > Key: CALCITE-1235 > URL: https://issues.apache.org/jira/browse/CALCITE-1235 > Project: Calcite > Issue Type: Improvement > Components: cassandra >Affects Versions: 1.7.0 >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.8.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1253) Create Elasticsearch adapter for Calcite
[ https://issues.apache.org/jira/browse/CALCITE-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295699#comment-15295699 ] Michael Mior commented on CALCITE-1253: --- Checked out the PR for the VM. I think it would be nice to stick to Chef for provisioning, but what's there looks alright otherwise. Just testing building the VM now. > Create Elasticsearch adapter for Calcite > > > Key: CALCITE-1253 > URL: https://issues.apache.org/jira/browse/CALCITE-1253 > Project: Calcite > Issue Type: New Feature >Reporter: Subhobrata Dey >Assignee: Julian Hyde > > This JIRA ticket is created to propose the addition of the new Elasticsearch > adapter for Calcite. > The adapter exposes a SQL interface to elasticsearch which includes > projection, filtering, sort, fetch, offset queries. > I have provided a couple of PRs, the first one is for the elasticsearch > adapter & the second one is for enhancing the Vagrantfile for loading test > data required for running the Junits. > Currently, the support for aggregates is not provided. The work on it is in > progress. > Kindly evaluate my contribution & please consider it as an addition to the > calcite project. > Following PRs are provided: > https://github.com/apache/calcite/pull/236 > https://github.com/vlsi/calcite-test-dataset/pull/10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1253) Create Elasticsearch adapter for Calcite
[ https://issues.apache.org/jira/browse/CALCITE-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295714#comment-15295714 ] Michael Mior commented on CALCITE-1253: --- Of course I meant Puppet instead of Chef. I'll attribute that to jet lag :) > Create Elasticsearch adapter for Calcite > > > Key: CALCITE-1253 > URL: https://issues.apache.org/jira/browse/CALCITE-1253 > Project: Calcite > Issue Type: New Feature >Reporter: Subhobrata Dey >Assignee: Julian Hyde > > This JIRA ticket is created to propose the addition of the new Elasticsearch > adapter for Calcite. > The adapter exposes a SQL interface to elasticsearch which includes > projection, filtering, sort, fetch, offset queries. > I have provided a couple of PRs, the first one is for the elasticsearch > adapter & the second one is for enhancing the Vagrantfile for loading test > data required for running the Junits. > Currently, the support for aggregates is not provided. The work on it is in > progress. > Kindly evaluate my contribution & please consider it as an addition to the > calcite project. > Following PRs are provided: > https://github.com/apache/calcite/pull/236 > https://github.com/vlsi/calcite-test-dataset/pull/10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1234) Annotate table functions to allow pushing down project, filter
[
https://issues.apache.org/jira/browse/CALCITE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279248#comment-15279248
]
Michael Mior commented on CALCITE-1234:
---
Here's a few references you may want to take a look at
SOFA: An Extensible Logical Optimizer for UDF-heavy Dataflows
http://arxiv.org/abs/1311.6335
This is in the context of map-reduce code, but SOFA makes heavy use of
annotations and some of what they're doing may apply in a relational setting.
ANNOTATIONS FOR PARALLELIZATION OF USER-DEFINED FUNCTIONS WITH FLEXIBLE
PARTITIONING
http://www.freepatentsonline.com/y2015/0379076.html
This is a patent application and IANAL, so not sure if anything is usable here.
I'm also not really sure if Calcite takes advantage of any opportunities for
intra-query parallelism.
Query Optimization in the Presence of Foreign Functions
http://www.vldb.org/conf/1993/P529.PDF
This is an old one and maybe a bit too high-level to be useful but talks about
query optimization in the context of user-specified rewrite rules for UDFs.
> Annotate table functions to allow pushing down project, filter
> --
>
> Key: CALCITE-1234
> URL: https://issues.apache.org/jira/browse/CALCITE-1234
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> In general it is not possible to push relational operators through table
> functions but many table functions have properties that will allow push down:
> for instance, they might preserve fields, preserve row count, return rows in
> the same order. If we annotate a table function with these properties, we can
> automatically push down a Filter, and so forth.
> Some ideas:
> * {{PreservesFieldNames}}: If an output field has the same name as an input
> field, it is assumed to be the same field.
> * {{PreservesRows}}: Each input row causes exactly one output row, in the
> same order.
> * {{FiltersRows}}: Each input row causes at most one output row, in the same
> order.
> * {{PreservesFieldPositions}}: The leading N columns of the output are
> equivalent to the leading N columns of the input.
> If {{(PreservesFieldNames or PreservesFieldPositions) and (PreservesRows or
> FiltersRows)}}, it is safe to push down a Filter if all of the fields of the
> predicate exist in the input.
> Similarly pushing down a Project; and we can push down an Aggregate if
> {{PreservesRows}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[ https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283303#comment-15283303 ] Michael Mior commented on CALCITE-1235: --- [PR on GitHub|https://github.com/apache/calcite/pull/229]. If someone could take a look before I merge, that would be great! > Push down LIMIT in unfiltered Cassandra queries > --- > > Key: CALCITE-1235 > URL: https://issues.apache.org/jira/browse/CALCITE-1235 > Project: Calcite > Issue Type: Improvement > Components: cassandra >Affects Versions: 1.7.0 >Reporter: Michael Mior >Assignee: Michael Mior > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1210) Cassandra uuid filtering does not work
[
https://issues.apache.org/jira/browse/CALCITE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15251983#comment-15251983
]
Michael Mior commented on CALCITE-1210:
---
Thanks for reporting! I'll take this one [~julianhyde] (I don't think I can
assign myself). Shouldn't be too difficult of a fix.
> Cassandra uuid filtering does not work
> --
>
> Key: CALCITE-1210
> URL: https://issues.apache.org/jira/browse/CALCITE-1210
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Julian Hyde
>Priority: Minor
>
> It looks like the syntax for sending a uuid to cassandra is something like
> this
> {code}
> select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e
> {code}
> Which is a bare identifier, unquoted. So any filtering based on uuid's
> doesn't work. You get something like this:
> {code}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
> STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type
> uuid`
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1331) Submit Calcite paper to CIDR 2017
[ https://issues.apache.org/jira/browse/CALCITE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15394951#comment-15394951 ] Michael Mior commented on CALCITE-1331: --- I proposed some additions in the document. FWIW, I scanned the JIRA for potential upcoming work that we may want to include but nothing in particular stood out. > Submit Calcite paper to CIDR 2017 > - > > Key: CALCITE-1331 > URL: https://issues.apache.org/jira/browse/CALCITE-1331 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Submit a paper on Calcite to CIDR 2017. Submission is [due > 8/21|http://cidrdb.org/cidr2017/cfp.html]. > [~jcamachorodriguez] has [started work on the paper LaTeX > format|https://github.com/jcamachor/calcite-latex]. > We might be able to pull in content from [previous > talks|http://calcite.apache.org/community/#talks]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1331) Submit Calcite paper to CIDR 2017
[ https://issues.apache.org/jira/browse/CALCITE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397681#comment-15397681 ] Michael Mior commented on CALCITE-1331: --- Unfortunately Monday is a holiday here and I'll be away travelling. I may be available to join by phone if that's useful. I believe it's possible to dial someone in via Hangouts. > Submit Calcite paper to CIDR 2017 > - > > Key: CALCITE-1331 > URL: https://issues.apache.org/jira/browse/CALCITE-1331 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Submit a paper on Calcite to CIDR 2017. Submission is [due > 8/21|http://cidrdb.org/cidr2017/cfp.html]. > [~jcamachorodriguez] has [started work on the paper LaTeX > format|https://github.com/jcamachor/calcite-latex]. > We might be able to pull in content from [previous > talks|http://calcite.apache.org/community/#talks]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1304) Add wrapper for Apache Metamodel adapters
[ https://issues.apache.org/jira/browse/CALCITE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358279#comment-15358279 ] Michael Mior commented on CALCITE-1304: --- If I'm understanding this correctly, the idea is that there would be a separate Metamodel adapter in Calcite. In this case the adapter would need to convert the query into the Metamodel query API. Metamodel in turn will need to construct native calls to the underlying datastore. I can't imagine there won't be _some_ loss of efficiency here, although hopefully fairly negligible. > Add wrapper for Apache Metamodel adapters > - > > Key: CALCITE-1304 > URL: https://issues.apache.org/jira/browse/CALCITE-1304 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Apache Metamodel has adapters for a lot of data sources. It would be great if > those adapters could be re-used as Calcite adapters (and potentially Drill > adapters also). I was speaking to [~kaspersor] (Metamodel PMC member) today > and he likes the idea. > I don't know whether there would be any loss of efficiency going through a > wrapper, but I suspect not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1304) Add wrapper for Apache Metamodel adapters
[ https://issues.apache.org/jira/browse/CALCITE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358282#comment-15358282 ] Michael Mior commented on CALCITE-1304: --- It would be interesting to compare some queries against a datastore with a native Calcite adapter vs going through Metamodel for those stores which have an adapter in both. > Add wrapper for Apache Metamodel adapters > - > > Key: CALCITE-1304 > URL: https://issues.apache.org/jira/browse/CALCITE-1304 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Apache Metamodel has adapters for a lot of data sources. It would be great if > those adapters could be re-used as Calcite adapters (and potentially Drill > adapters also). I was speaking to [~kaspersor] (Metamodel PMC member) today > and he likes the idea. > I don't know whether there would be any loss of efficiency going through a > wrapper, but I suspect not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1331) Submit Calcite paper to CIDR 2017
[ https://issues.apache.org/jira/browse/CALCITE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420909#comment-15420909 ] Michael Mior commented on CALCITE-1331: --- I pushed a draft of the section on adapters to the Git repository. Unfortunately I wasn't able to complete the draft of the data model section yet. I'll be away on vacation until Thursday evening and I can pick that back up then. > Submit Calcite paper to CIDR 2017 > - > > Key: CALCITE-1331 > URL: https://issues.apache.org/jira/browse/CALCITE-1331 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Submit a paper on Calcite to CIDR 2017. Submission is [due > 8/21|http://cidrdb.org/cidr2017/cfp.html]. > [~jcamachorodriguez] has [started work on the paper LaTeX > format|https://github.com/jcamachor/calcite-latex]. > We might be able to pull in content from [previous > talks|http://calcite.apache.org/community/#talks]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1566) Better documentation on the use of materialized views
[ https://issues.apache.org/jira/browse/CALCITE-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828544#comment-15828544 ] Michael Mior commented on CALCITE-1566: --- Thanks for the suggestions! Agreed that it would be great to have more scenarios from other adapters. If you could write something for Phoenix that would be appreciated. I added a bit more on MaterializedViewSubstitutionVisitor as well as a simple example I pulled from the Javadoc. > Better documentation on the use of materialized views > - > > Key: CALCITE-1566 > URL: https://issues.apache.org/jira/browse/CALCITE-1566 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior > Labels: documentation > Fix For: 1.12.0 > > > As discussed in > [CALCITE-1389|https://issues.apache.org/jira/browse/CALCITE-1389], it would > be helpful to have additional documentation on how Calcite makes use of > materialized views. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-917) Add support for EXPLAIN PLAN AS JSON
[ https://issues.apache.org/jira/browse/CALCITE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548533#comment-15548533 ] Michael Mior commented on CALCITE-917: -- Sorry, I had kind of forgotten about this. Here's a pull request. If you could review, that would be great. https://github.com/apache/calcite/pull/295 > Add support for EXPLAIN PLAN AS JSON > > > Key: CALCITE-917 > URL: https://issues.apache.org/jira/browse/CALCITE-917 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jacques Nadeau >Assignee: Michael Mior > Labels: newbie > > Explain plan currently supports outputting text and xml. Let's add an option > to explain plan "AS JSON". Drill will definitely plug into this. Other > systems could as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548597#comment-15548597 ] Michael Mior commented on CALCITE-1389: --- Sorry, somehow I didn't see your earlier comment. Not sure how I missed this, but I added it now. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-917) Add support for EXPLAIN PLAN AS JSON
[ https://issues.apache.org/jira/browse/CALCITE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15556116#comment-15556116 ] Michael Mior commented on CALCITE-917: -- That's great! Something I thought about and probably should have done myself. Thanks and thanks for adding the test as well :) Looks good to me. > Add support for EXPLAIN PLAN AS JSON > > > Key: CALCITE-917 > URL: https://issues.apache.org/jira/browse/CALCITE-917 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jacques Nadeau >Assignee: Michael Mior > Labels: newbie > Fix For: 1.11.0 > > > Explain plan currently supports outputting text and xml. Let's add an option > to explain plan "AS JSON". Drill will definitely plug into this. Other > systems could as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
Michael Mior created CALCITE-1389: - Summary: Add rule to perform rewriting of queries using materialized views with joins Key: CALCITE-1389 URL: https://issues.apache.org/jira/browse/CALCITE-1389 Project: Calcite Issue Type: Improvement Components: core Reporter: Michael Mior Assignee: Michael Mior I've been looking into implementing the approach from the following paper. It's very nicely written and easy to follow. It also doesn't require trying different join permutations. I'm starting with several additional restrictions (only equijoins, no aggregations, etc.) ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf Thanks to [~jcamachorodriguez] for his help in sorting out some issues with the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527032#comment-15527032 ] Michael Mior commented on CALCITE-1389: --- Pull request available on GitHub. https://github.com/apache/calcite/pull/284 > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CALCITE-1482) Resource leak on creation of CassandraSchema
[
https://issues.apache.org/jira/browse/CALCITE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior reopened CALCITE-1482:
---
> Resource leak on creation of CassandraSchema
>
>
> Key: CALCITE-1482
> URL: https://issues.apache.org/jira/browse/CALCITE-1482
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.10.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> Found via the following Coverity scan
> {noformat}
> *** CID 138163: Resource leaks (RESOURCE_LEAK)
> /cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraSchema.java:
> 115 in
> org.apache.calcite.adapter.cassandra.CassandraSchema.(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String,
> org.apache.calcite.schema.SchemaPlus, java.lang.String)()
> 109 } catch (Exception e) {
> 110 throw new RuntimeException(e);
> 111 }
> 112 this.parentSchema = parentSchema;
> 113 this.name = name;
> 114
> >>CID 138163: Resource leaks (RESOURCE_LEAK)
> >>Ignoring resource created by
> >> "org.apache.calcite.runtime.Hook.TRIMMED.add(this.new
> >> org.apache.calcite.adapter.cassandra.CassandraSchema.1())" leaks it.
> 115 Hook.TRIMMED.add(new Function() {
> 116 public Void apply(RelNode node) {
> 117 CassandraSchema.this.addMaterializedViews();
> 118 return null;
> 119 }
> 120 });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1482) Resource leak on creation of CassandraSchema
[
https://issues.apache.org/jira/browse/CALCITE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-1482.
---
Resolution: Fixed
> Resource leak on creation of CassandraSchema
>
>
> Key: CALCITE-1482
> URL: https://issues.apache.org/jira/browse/CALCITE-1482
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.10.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> Found via the following Coverity scan
> {noformat}
> *** CID 138163: Resource leaks (RESOURCE_LEAK)
> /cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraSchema.java:
> 115 in
> org.apache.calcite.adapter.cassandra.CassandraSchema.(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String,
> org.apache.calcite.schema.SchemaPlus, java.lang.String)()
> 109 } catch (Exception e) {
> 110 throw new RuntimeException(e);
> 111 }
> 112 this.parentSchema = parentSchema;
> 113 this.name = name;
> 114
> >>CID 138163: Resource leaks (RESOURCE_LEAK)
> >>Ignoring resource created by
> >> "org.apache.calcite.runtime.Hook.TRIMMED.add(this.new
> >> org.apache.calcite.adapter.cassandra.CassandraSchema.1())" leaks it.
> 115 Hook.TRIMMED.add(new Function() {
> 116 public Void apply(RelNode node) {
> 117 CassandraSchema.this.addMaterializedViews();
> 118 return null;
> 119 }
> 120 });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1440) Implement planner for converting multiple SQL statements to unified RelNode Tree
[
https://issues.apache.org/jira/browse/CALCITE-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1440:
--
Description:
This can be implemented as a separate planner or in {{VolcanoPlanner}} itself.
The planner should take multiple SQL statements as input and return a unified
{{RelNode}} tree.
Example of above is as follows:
{{SELECT COL1, COL2 FROM TABLE WHERE COL3 > 10;}}
{{SELECT COL1, COL2 FROM TABLE WHERE COL4 = 'abc';}}
The above 2 statements have a common path and hence can provide a unified
{{RelNode}} tree as follows:
{noformat}
[Scan] -> [Project (COL1, COL2)] -> [Filter (COL4 = 'abc')] -> [Delta]
|
V
[Filter (COL3 > 10)]
|
v
[Delta]
{noformat}
was:
This can be implemented as a seperate planner or in VolcanoPlanner itself. The
planner should take multiple SQL statements as input and return a unified
RelNode Tree.
Example of above is as follows:
SELECT COL1, COL2 FROM TABLE WHERE COL3 > 10;
SELECT COL1, COL2 FROM TABLE WHERE COL4 = 'abc';
Above 2 statements has a common path and hence can provide an unified RelNode
tree as follows:
[Scan] -> [Project (COL1, COL2)] -> [Filter (COL4 = 'abc')] -> [Delta]
|
V
[Filter (COL3 > 10)]
|
v
[Delta]
> Implement planner for converting multiple SQL statements to unified RelNode
> Tree
>
>
> Key: CALCITE-1440
> URL: https://issues.apache.org/jira/browse/CALCITE-1440
> Project: Calcite
> Issue Type: New Feature
>Reporter: Chinmay Kolhatkar
>Assignee: Julian Hyde
>
> This can be implemented as a separate planner or in {{VolcanoPlanner}}
> itself. The planner should take multiple SQL statements as input and return a
> unified {{RelNode}} tree.
> Example of above is as follows:
> {{SELECT COL1, COL2 FROM TABLE WHERE COL3 > 10;}}
> {{SELECT COL1, COL2 FROM TABLE WHERE COL4 = 'abc';}}
> The above 2 statements have a common path and hence can provide a unified
> {{RelNode}} tree as follows:
> {noformat}
> [Scan] -> [Project (COL1, COL2)] -> [Filter (COL4 = 'abc')] -> [Delta]
> |
> V
> [Filter (COL3 > 10)]
> |
> v
> [Delta]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585254#comment-15585254 ] Michael Mior commented on CALCITE-1443: --- Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=d0f7dd3 > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585253#comment-15585253 ] Michael Mior commented on CALCITE-1443: --- I updated to add a line explaining that the username and password can be specified. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585567#comment-15585567 ] Michael Mior commented on CALCITE-1389: --- Sounds like a great idea. I will admit that I don't have a great handle on some of the aspects you mentioned, but I think all of those should be included in the documentation. I think this is worth opening up a separate issue for which I'll do if there are no objections. Maybe we can get some stable documentation on existing use of MVs before pushing this further. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1443: -- Fix Version/s: 1.11.0 > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584197#comment-15584197 ] Michael Mior commented on CALCITE-1443: --- I can update to add information on authentication if you prefer, but the current docs are still valid. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1491) Excel Adaptor
[ https://issues.apache.org/jira/browse/CALCITE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1491: -- Description: Build Excel Adaptor for Apache Calcite like CSV Adaptor (was: Build Excel Adapter for Apache calcite like CSV Adapter) > Excel Adaptor > - > > Key: CALCITE-1491 > URL: https://issues.apache.org/jira/browse/CALCITE-1491 > Project: Calcite > Issue Type: New Feature >Reporter: Prasad V S >Assignee: Julian Hyde > > Build Excel Adaptor for Apache Calcite like CSV Adaptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1491) Excel Adapter
[ https://issues.apache.org/jira/browse/CALCITE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1491: -- Description: Build Excel Adapter for Apache calcite like CSV Adapter (was: Build Excel Adaptor for Apache calcite like CSV Adaptor) Summary: Excel Adapter (was: Excel Adaptor) > Excel Adapter > - > > Key: CALCITE-1491 > URL: https://issues.apache.org/jira/browse/CALCITE-1491 > Project: Calcite > Issue Type: New Feature >Reporter: Prasad V S >Assignee: Julian Hyde > > Build Excel Adapter for Apache calcite like CSV Adapter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1491) Excel Adaptor
[ https://issues.apache.org/jira/browse/CALCITE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1491: -- Summary: Excel Adaptor (was: Excel Adapter) > Excel Adaptor > - > > Key: CALCITE-1491 > URL: https://issues.apache.org/jira/browse/CALCITE-1491 > Project: Calcite > Issue Type: New Feature >Reporter: Prasad V S >Assignee: Julian Hyde > > Build Excel Adapter for Apache calcite like CSV Adapter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1331) Submit Calcite paper to CIDR 2017
[ https://issues.apache.org/jira/browse/CALCITE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658638#comment-15658638 ] Michael Mior commented on CALCITE-1331: --- That sounds good to me as well but if the camera ready deadline is February 20th, it sounds like the submission deadline has probably already passed or is coming up very soon. Last year the camera ready deadline was March 15th and the initial submission deadline was December 1st. Another option to consider is the VLDB innovative systems and applications papers (http://www.vldb.org/2017/cfp_research_track.php). VLDB has a rolling deadline every month. > Submit Calcite paper to CIDR 2017 > - > > Key: CALCITE-1331 > URL: https://issues.apache.org/jira/browse/CALCITE-1331 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Submit a paper on Calcite to CIDR 2017. Submission is [due > 8/21|http://cidrdb.org/cidr2017/cfp.html]. > [~jcamachorodriguez] has [started work on the paper LaTeX > format|https://github.com/jcamachor/calcite-latex]. > We might be able to pull in content from [previous > talks|http://calcite.apache.org/community/#talks]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626156#comment-15626156 ] Michael Mior commented on CALCITE-1389: --- Any suggestions on how I can selectively enable the rule during tests? I'd like to keep the test case in MaterializationTest, but it will fail with the MaterializedViewJoinRule not enabled. I don't see an obvious to have it enabled just for the tests. (Ideally, just for that single test). > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CALCITE-1482) Resource leak on creation of CassandraSchema
[
https://issues.apache.org/jira/browse/CALCITE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior closed CALCITE-1482.
-
Resolution: Fixed
Fix Version/s: 1.11.0
> Resource leak on creation of CassandraSchema
>
>
> Key: CALCITE-1482
> URL: https://issues.apache.org/jira/browse/CALCITE-1482
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.10.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> Found via the following Coverity scan
> {noformat}
> *** CID 138163: Resource leaks (RESOURCE_LEAK)
> /cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraSchema.java:
> 115 in
> org.apache.calcite.adapter.cassandra.CassandraSchema.(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String,
> org.apache.calcite.schema.SchemaPlus, java.lang.String)()
> 109 } catch (Exception e) {
> 110 throw new RuntimeException(e);
> 111 }
> 112 this.parentSchema = parentSchema;
> 113 this.name = name;
> 114
> >>CID 138163: Resource leaks (RESOURCE_LEAK)
> >>Ignoring resource created by
> >> "org.apache.calcite.runtime.Hook.TRIMMED.add(this.new
> >> org.apache.calcite.adapter.cassandra.CassandraSchema.1())" leaks it.
> 115 Hook.TRIMMED.add(new Function() {
> 116 public Void apply(RelNode node) {
> 117 CassandraSchema.this.addMaterializedViews();
> 118 return null;
> 119 }
> 120 });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1482) Resource leak on creation of CassandraSchema
[
https://issues.apache.org/jira/browse/CALCITE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637050#comment-15637050
]
Michael Mior commented on CALCITE-1482:
---
Done. Sorry for the delay, just wanted to run the integration tests first to
make sure nothing was amiss.
> Resource leak on creation of CassandraSchema
>
>
> Key: CALCITE-1482
> URL: https://issues.apache.org/jira/browse/CALCITE-1482
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.10.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> Found via the following Coverity scan
> {noformat}
> *** CID 138163: Resource leaks (RESOURCE_LEAK)
> /cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraSchema.java:
> 115 in
> org.apache.calcite.adapter.cassandra.CassandraSchema.(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String,
> org.apache.calcite.schema.SchemaPlus, java.lang.String)()
> 109 } catch (Exception e) {
> 110 throw new RuntimeException(e);
> 111 }
> 112 this.parentSchema = parentSchema;
> 113 this.name = name;
> 114
> >>CID 138163: Resource leaks (RESOURCE_LEAK)
> >>Ignoring resource created by
> >> "org.apache.calcite.runtime.Hook.TRIMMED.add(this.new
> >> org.apache.calcite.adapter.cassandra.CassandraSchema.1())" leaks it.
> 115 Hook.TRIMMED.add(new Function() {
> 116 public Void apply(RelNode node) {
> 117 CassandraSchema.this.addMaterializedViews();
> 118 return null;
> 119 }
> 120 });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1482) Resource leak on creation of CassandraSchema
[
https://issues.apache.org/jira/browse/CALCITE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637136#comment-15637136
]
Michael Mior commented on CALCITE-1482:
---
Sorry about that. I know I've made the same mistake before and I thought I
remembered correctly this time.
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=dd3782e73c7ef16abeeb7bb1a06f157a68c5fce7
> Resource leak on creation of CassandraSchema
>
>
> Key: CALCITE-1482
> URL: https://issues.apache.org/jira/browse/CALCITE-1482
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.10.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> Found via the following Coverity scan
> {noformat}
> *** CID 138163: Resource leaks (RESOURCE_LEAK)
> /cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraSchema.java:
> 115 in
> org.apache.calcite.adapter.cassandra.CassandraSchema.(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String,
> org.apache.calcite.schema.SchemaPlus, java.lang.String)()
> 109 } catch (Exception e) {
> 110 throw new RuntimeException(e);
> 111 }
> 112 this.parentSchema = parentSchema;
> 113 this.name = name;
> 114
> >>CID 138163: Resource leaks (RESOURCE_LEAK)
> >>Ignoring resource created by
> >> "org.apache.calcite.runtime.Hook.TRIMMED.add(this.new
> >> org.apache.calcite.adapter.cassandra.CassandraSchema.1())" leaks it.
> 115 Hook.TRIMMED.add(new Function() {
> 116 public Void apply(RelNode node) {
> 117 CassandraSchema.this.addMaterializedViews();
> 118 return null;
> 119 }
> 120 });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626881#comment-15626881 ] Michael Mior commented on CALCITE-1389: --- Thanks! That did the trick. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1481) Documentation for materialized views
Michael Mior created CALCITE-1481: - Summary: Documentation for materialized views Key: CALCITE-1481 URL: https://issues.apache.org/jira/browse/CALCITE-1481 Project: Calcite Issue Type: Improvement Reporter: Michael Mior Assignee: Julian Hyde There are many different ways to deal with materialized views within Calcite. Currently the documentation on this is somewhat lacking. A few points to consider: * Materialized views maintained by adapters but exposed to Calcite (e.g. Cassandra) * Materialized views created within Calcite * Planner rules that perform rewriting to use materialized views -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626883#comment-15626883 ] Michael Mior commented on CALCITE-1389: --- Fixed in [435b6d4|https://github.com/apache/calcite/commit/435b6d47b195f55e4a926da3ba27f3bb0e5699cc]. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[
https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15623037#comment-15623037
]
Michael Mior commented on CALCITE-1389:
---
I think it might be good to disable this rule by default. That is, avoid adding
it to the default planner constructed in {{CalcitePrepareImpl}}. Thoughts? The
documentation would mention that it is necessary to manually add this rule and
the goal would still be to eventually have this enabled by default.
> Add rule to perform rewriting of queries using materialized views with joins
>
>
> Key: CALCITE-1389
> URL: https://issues.apache.org/jira/browse/CALCITE-1389
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> I've been looking into implementing the approach from the following paper.
> It's very nicely written and easy to follow. It also doesn't require trying
> different join permutations. I'm starting with several additional
> restrictions (only equijoins, no aggregations, etc.)
> ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf
> Thanks to [~jcamachorodriguez] for his help in sorting out some issues with
> the rule so far.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565650#comment-15565650 ] Michael Mior commented on CALCITE-1389: --- Definitely far from production quality IMO, but I think interesting enough to be included. I'll have to think over what would happen in each of the scenarios you presented above, but it's definitely not very robust at this point. Some more test cases clarifying the current behaviour are definitely in order. That said, I've tried to make the rule fairly restrictive so it won't try to rewrite cases that aren't correctly handled. For example, I check that all the joins are inner joins. My target for this is conjunctive queries with equality predicates and simple field references in the SELECT clause. bq. Or if the the MV doesn't use any table twice, but the MV does? I assume one of the references to MV above should be query? I haven't thought specifically about the complexity of this approach, but I would expect poor performance with a large number of MVs. The paper gives some ideas on how to build index structures to optimize this. On a related note, if you have any suggestions on where an appropriate place in the code would be to construct such indexes and what object should own the index data, that would be helpful. As for where this fits into planning, I think this could still work as part of Volcano. Using MVs when possible is not always the best choice. It also enables cost-based selection of multiple MVs when that's an option. Thanks for the style suggestions. I fixed those issues. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-1443: - Assignee: Michael Mior > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582844#comment-15582844 ] Michael Mior commented on CALCITE-1443: --- Thanks for the patch! I'd prefer to keep backwards compatibility, but check out [this branch|https://github.com/michaelmior/calcite/tree/1443-cassandra-auth] and see if it works for you. If it does I'll merge this soon and it will be in the next release of Calcite. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1566) Better documentation on the use of materialized views
[ https://issues.apache.org/jira/browse/CALCITE-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15805104#comment-15805104 ] Michael Mior commented on CALCITE-1566: --- [~julianhyde] [~maryannxue] Could you take a look at the [first pass|https://github.com/michaelmior/calcite/blob/1566-mat-view-doc/site/_docs/materialized_views.md] at this documentation? I'd appreciate any feedback. > Better documentation on the use of materialized views > - > > Key: CALCITE-1566 > URL: https://issues.apache.org/jira/browse/CALCITE-1566 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior > Labels: documentation > Fix For: 1.12.0 > > > As discussed in > [CALCITE-1389|https://issues.apache.org/jira/browse/CALCITE-1389], it would > be helpful to have additional documentation on how Calcite makes use of > materialized views. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1566) Better documentation on the use of materialized views
Michael Mior created CALCITE-1566: - Summary: Better documentation on the use of materialized views Key: CALCITE-1566 URL: https://issues.apache.org/jira/browse/CALCITE-1566 Project: Calcite Issue Type: Improvement Reporter: Michael Mior Assignee: Michael Mior Fix For: 1.12.0 As discussed in [CALCITE-1389|https://issues.apache.org/jira/browse/CALCITE-1389], it would be helpful to have additional documentation on how Calcite makes use of materialized views. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1718) Incorrect data type for context in Druid adapter
[
https://issues.apache.org/jira/browse/CALCITE-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936811#comment-15936811
]
Michael Mior commented on CALCITE-1718:
---
I get the response below. It looks like either way {{"true}} is still the
recommended choice though, correct?
{noformat}
{
"error" : "java.lang.Boolean cannot be cast to java.lang.String"
}
{noformat}
> Incorrect data type for context in Druid adapter
>
>
> Key: CALCITE-1718
> URL: https://issues.apache.org/jira/browse/CALCITE-1718
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Michael Mior
>Assignee: Michael Mior
>
> The context {{skipEmptyBuckets}} added in
> [CALCITE-1589|https://issues.apache.org/jira/browse/CALCITE-1589] was given
> the boolean value {{true}}. The [Druid
> documentation|http://druid.io/docs/latest/querying/timeseriesquery.html]
> shows that this should be the string {{"true"}}. I get a test failure on
> Druid 0.9.2 because of this discrepancy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CALCITE-1716) Cassandra integration tests broken due to change in CAST behavior
[ https://issues.apache.org/jira/browse/CALCITE-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-1716. --- Resolution: Resolved > Cassandra integration tests broken due to change in CAST behavior > - > > Key: CALCITE-1716 > URL: https://issues.apache.org/jira/browse/CALCITE-1716 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.12.0 > > > Small fixes needed to expected test output. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1716) Cassandra integration tests broken due to change in CAST behavior
[ https://issues.apache.org/jira/browse/CALCITE-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933593#comment-15933593 ] Michael Mior commented on CALCITE-1716: --- Fixed in [9c8b59797|https://github.com/apache/calcite/commit/9c8b5979754855d06226f6c3879aee04cabcb3af]. > Cassandra integration tests broken due to change in CAST behavior > - > > Key: CALCITE-1716 > URL: https://issues.apache.org/jira/browse/CALCITE-1716 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.12.0 > > > Small fixes needed to expected test output. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1715) Cassandra adapter is broken by Guava change
[
https://issues.apache.org/jira/browse/CALCITE-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933476#comment-15933476
]
Michael Mior commented on CALCITE-1715:
---
Bad news. The Cassandra driver appears to depend on Guava 16.0.1. It works with
18.0, but not with 20.0. This is due to {{Futures.transform}} being renamed to
{{Futures.transformAsync}} with the old name finally dropped in 20.0. Easiest
solution would be to upgrade to 19.0 instead of 20.0 for the time being.
> Cassandra adapter is broken by Guava change
> ---
>
> Key: CALCITE-1715
> URL: https://issues.apache.org/jira/browse/CALCITE-1715
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.12.0
>Reporter: Michael Mior
>
> The Cassandra driver appears to be incompatible with Guava 20. Works fine
> when downgrading to Guava 18. Stack trace of the exception produced when
> trying to connect via sqlline below:
> {noformat}
> java.lang.NoSuchMethodError:
> com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
> at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
> at
> com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
> at
> com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
> at
> com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
> at
> com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
> at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
> at com.datastax.driver.core.Cluster.init(Cluster.java:159)
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
> at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
> at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
> at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
> at sqlline.Commands.connect(Commands.java:1064)
> at sqlline.Commands.connect(Commands.java:996)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:809)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1715) Cassandra adapter is broken by Guava change
[
https://issues.apache.org/jira/browse/CALCITE-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933561#comment-15933561
]
Michael Mior commented on CALCITE-1715:
---
Pushed
[1e405d63e|https://github.com/apache/calcite/commit/1e405d63e6a25d3411ecc0cfe8f13f0c5d30068a]
which changes the Guava version to 19.0. Verified that all tests pass.
Cassandra integration tests still fail due to an unrelated issue with some
changes to the planner output. Will fix shortly.
> Cassandra adapter is broken by Guava change
> ---
>
> Key: CALCITE-1715
> URL: https://issues.apache.org/jira/browse/CALCITE-1715
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.12.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.12.0
>
>
> The Cassandra driver appears to be incompatible with Guava 20. Works fine
> when downgrading to Guava 18. Stack trace of the exception produced when
> trying to connect via sqlline below:
> {noformat}
> java.lang.NoSuchMethodError:
> com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
> at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
> at
> com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
> at
> com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
> at
> com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
> at
> com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
> at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
> at com.datastax.driver.core.Cluster.init(Cluster.java:159)
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
> at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
> at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
> at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
> at sqlline.Commands.connect(Commands.java:1064)
> at sqlline.Commands.connect(Commands.java:996)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:809)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1716) Cassandra integration tests broken due to change in CAST behavior
Michael Mior created CALCITE-1716: - Summary: Cassandra integration tests broken due to change in CAST behavior Key: CALCITE-1716 URL: https://issues.apache.org/jira/browse/CALCITE-1716 Project: Calcite Issue Type: Bug Components: cassandra Reporter: Michael Mior Assignee: Michael Mior Fix For: 1.12.0 Small fixes needed to expected test output. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CALCITE-1715) Cassandra adapter is broken by Guava change
[
https://issues.apache.org/jira/browse/CALCITE-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-1715.
---
Resolution: Resolved
> Cassandra adapter is broken by Guava change
> ---
>
> Key: CALCITE-1715
> URL: https://issues.apache.org/jira/browse/CALCITE-1715
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.12.0
>Reporter: Michael Mior
>Assignee: Michael Mior
> Fix For: 1.12.0
>
>
> The Cassandra driver appears to be incompatible with Guava 20. Works fine
> when downgrading to Guava 18. Stack trace of the exception produced when
> trying to connect via sqlline below:
> {noformat}
> java.lang.NoSuchMethodError:
> com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
> at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
> at
> com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
> at
> com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
> at
> com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
> at
> com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
> at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
> at com.datastax.driver.core.Cluster.init(Cluster.java:159)
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
> at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
> at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
> at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
> at sqlline.Commands.connect(Commands.java:1064)
> at sqlline.Commands.connect(Commands.java:996)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:809)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1715) Cassandra adapter is broken by Guava change
[
https://issues.apache.org/jira/browse/CALCITE-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1715:
--
Description:
The Cassandra driver appears to be incompatible with Guava 20. Works fine when
downgrading to Guava 18. Stack trace of the exception produced when trying to
connect via sqlline below:
{noformat}
java.lang.NoSuchMethodError:
com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
at com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
at com.datastax.driver.core.Cluster.init(Cluster.java:159)
at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
at
org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
at
org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
at
org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
at
org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
at sqlline.Commands.connect(Commands.java:1064)
at sqlline.Commands.connect(Commands.java:996)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:809)
at sqlline.SqlLine.begin(SqlLine.java:686)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:291)
{noformat}
was:
The Cassandra drive appears to be incompatible with Guava 20. Works fine when
downgrading to Guava 18. Stack trace of the exception produced when trying to
connect via sqlline below:
{noformat}
java.lang.NoSuchMethodError:
com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
at com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
at com.datastax.driver.core.Cluster.init(Cluster.java:159)
at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
at
org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
at
org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
at
org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
at
org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
at
[jira] [Commented] (CALCITE-1715) Cassandra adapter is broken by Guava change
[
https://issues.apache.org/jira/browse/CALCITE-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933492#comment-15933492
]
Michael Mior commented on CALCITE-1715:
---
Good news is that the next release of the Cassandra driver will provide Guava
20.0 compatibility. See [their
JIRA|https://datastax-oss.atlassian.net/browse/JAVA-1328] and the associated
[pull request|https://github.com/datastax/java-driver/pull/784]. We could just
include a warning in the release notes that anyone using Cassandra will have to
explicitly rely on Guava 19.0 and then hopefully have this fixed in the next
Calcite release if the Cassandra driver is updated by then.
> Cassandra adapter is broken by Guava change
> ---
>
> Key: CALCITE-1715
> URL: https://issues.apache.org/jira/browse/CALCITE-1715
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.12.0
>Reporter: Michael Mior
>
> The Cassandra driver appears to be incompatible with Guava 20. Works fine
> when downgrading to Guava 18. Stack trace of the exception produced when
> trying to connect via sqlline below:
> {noformat}
> java.lang.NoSuchMethodError:
> com.google.common.util.concurrent.Futures.transform(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/AsyncFunction;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;
> at com.datastax.driver.core.Connection.initAsync(Connection.java:182)
> at
> com.datastax.driver.core.Connection$Factory.open(Connection.java:796)
> at
> com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:253)
> at
> com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
> at
> com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
> at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1483)
> at com.datastax.driver.core.Cluster.init(Cluster.java:159)
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:330)
> at com.datastax.driver.core.Cluster.connect(Cluster.java:280)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchema.(CassandraSchema.java:109)
> at
> org.apache.calcite.adapter.cassandra.CassandraSchemaFactory.create(CassandraSchemaFactory.java:40)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:215)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:143)
> at org.apache.calcite.model.ModelHandler.(ModelHandler.java:85)
> at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:145)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
> at sqlline.Commands.connect(Commands.java:1064)
> at sqlline.Commands.connect(Commands.java:996)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:809)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
