Thanks a lot, Michael and Jordan. I got it working with the suggestion. I'll send a pull request later for you guys to help review.
Also, I got another question. When I run a PrepareStatement in calcite, I also want to push down part of the PrepareStatement in CQL to cassandra. For example, Assuming the cassandra table contains field: a, b, c, and a is the only primary key. calcite PrepareStatement is: select a, b, c from table1 where a = ? and b < ?; I want to push down CQL PrepareStatement: select a, b, c from table1 where a = ? to cassandra, and store the cassandra PrepareStatement inside the calcite PrepareStatement. And when we bind the data to execute the calcite PrepareStatement, I need to be able to retrieve the stored cassandra PrepareStatement and bind the data for it to execute the cassandra query. I would love to get some advice on how to implement this. Thanks a lot. On Wed, Aug 3, 2016 at 1:22 PM, [email protected] < [email protected]> wrote: > Sure, I'm no Cassandra expert and obviously the implementation needs to > handle whatever actually can be pushed down to C*. One should not follow my > advice precisely. The methods that are required to determine whether a > predicate is supported are already present in CassandraFilterRule. I was > just commenting on how one would go about splitting a filter based on what > is supported/not supported. So, replace "equality predicate" with "whatever > Cassandra supports" and use the existing isEqualityOnKey method. > > > On Aug 3, 2016, at 11:44 AM, Michael Mior <[email protected]> wrote: > > > > It's more complicated than that. For equality predicates, it's a matter > of > > splitting out equality predicates involving a field and a literal. > > Cassandra can't handle predicates involving expressions or equality > between > > fields. Cassandra can also handle some range predicates if the partition > > key is already restricted by an equality predicate and the range > predicate > > is part o the clustering key. > > > > Cheers, > > -- > > Michael Mior > > [email protected] > > > > 2016-08-03 14:21 GMT-04:00 [email protected] < > > [email protected]>: > > > >> It's just a matter of splitting out equality predicates. What I would do > >> is create a Filter rule that splits the filter based on whether a > predicate > >> is an equality. If the Filter is split, the rule returns a Filter with > the > >> equality predicates as inputs to the non-equality predicates. That > should > >> allow the CassandraFilterRule to convert the Filter with equality > >> predicates and for the rest of the predicates above to be implemented in > >> Enumerable convention. > >> > >> You can look at the rules in core for some examples of splitting > >> expressions. Just ensure equality predicates are pushed down or you can > >> implement a rule for pushing them down past other filters. > >> > >>> On Aug 3, 2016, at 10:57 AM, Shuyi Chen <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> I am working on improving the cassandra adapter. Right now, I found > that > >> if > >>> my filter contains non-primary keys, calcite will just reject the > filter > >>> and just execute a no-filter cql query which is bad. I am wondering > how > >> I > >>> can split the filter into cassandra supported part and > >>> cassandra-non-supported part, and push down the cassandra supported > part > >> to > >>> cql. Below is an example. > >>> > >>> Assuming the cassandra table contains field: a, b, c, and a is the only > >>> primary key. > >>> > >>> calcite sql is: select a, b, c from table1 where a = 'xxx' and b < > 3223; > >>> > >>> I want to push down cql: select a, b, c from table1 where a = 'xxx' to > >>> cassandra, > >>> > >>> But right now, the cassandra adapter will only push down: select a, b, > c > >>> from table1, which is bad for cassandra. > >>> > >>> Thanks a lot. > >>> Shuyi > >>> > >>> -- > >>> "So you have to trust that the dots will somehow connect in your > future." > >> > -- "So you have to trust that the dots will somehow connect in your future."
