In the second approach, where would the Cassandra prepared statement be stored? I'm not sure I understand the lifecycle of Calcite statements. Is there ever a case where the same statement will be reused? If there's a convenient object to attach the Cassandra prepared statement to, that's great. If it's going to be necessary to maintain some sort of cache of these prepared statements, then I don't think it's worth it.
-- Michael Mior michael.m...@gmail.com 2016-08-04 21:07 GMT-04:00 Julian Hyde <jh...@apache.org>: > 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 <mm...@uwaterloo.ca> 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 > > michael.m...@gmail.com > > > > 2016-08-04 3:33 GMT-04:00 Shuyi Chen <suez1...@gmail.com>: > > > >> 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, jordan.halter...@gmail.com < > >> jordan.halter...@gmail.com> 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 <mm...@uwaterloo.ca> 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 > >>>> michael.m...@gmail.com > >>>> > >>>> 2016-08-03 14:21 GMT-04:00 jordan.halter...@gmail.com < > >>>> jordan.halter...@gmail.com>: > >>>> > >>>>> 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 <suez1...@gmail.com> 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." > >> > >
