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."
>> 

Reply via email to