I don’t recall whether there is a convenient “hook” in the adapter that gets called when Calcite prepares a statement. Maybe after the best plan has been found, and a CassandraRel.Implementor has finished walking over a tree of CassandraRel nodes the Implementor could send the statement to Cassandra and stash the resulting handle somewhere that it can be retrieved when the statement is executed. But the problem is where to stash that handle, and ensuring that the Cassandra connection lifecycle matches Calcite’s statement lifecycle.
A simpler approach is to prepare the Cassandra statement the first time the Calcite statement is executed, and re-use that same statement for subsequent executions. The first execute will take a little longer than the previous approach, but the lifecycle is simpler. Julian > On Aug 4, 2016, at 3:51 PM, Michael Mior <[email protected]> wrote: > > Great! Looking forward to reviewing the PR. Unfortunately I'm not really > familiar with the PreparedStatement implementation in Calcite but I don't > believe it's currently possible to implement adapter-specific behaviour > prepared statements. At this point I think preparing statements only serves > to remove the overhead of parsing the query. I'm happy to have someone else > correct me if this is not the case. > > -- > Michael Mior > [email protected] > > 2016-08-04 3:33 GMT-04:00 Shuyi Chen <[email protected]>: > >> 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." >>
