[jira] [Commented] (CASSANDRA-10217) Support custom query expressions in SELECT

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790958#comment-14790958 ] 

Sam Tunnicliffe commented on CASSANDRA-10217:
---------------------------------------------

I've pushed a rebased version for review. There's some overlap in {{CustomIndexTest}} with the branch up for review in CASSANDRA-10216. There I've moved the test class from the {{org.apache.cassandra.index.internal}} to {{org.apache.cassandra.index}}, which I haven't here (just FTR if anyone looks at both).

Patches:
* [3.0 branch|https://github.com/beobal/cassandra/tree/10217-3.0]
* [trunk branch|https://github.com/beobal/cassandra/tree/10217-trunk]

CI Tests:
* [3.0 testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10217-3.0-testall/]
* [3.0 dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10217-trunk-dtest/]
* [trunk testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10217-trunk-testall/]
* [trunk dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10217-trunk-dtest/]


> Support custom query expressions in SELECT
> ------------------------------------------
>
>                 Key: CASSANDRA-10217
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10217
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.0.0 rc1
>
>
> (Broken out of CASSANDRA-10124)
> Custom index implementations often support query expressions which do not fit the structure of CQL. To support these, it has been necessary to add a fake column to the base table and query that using the custom syntax. Taking an example from the [Stratio docs|https://github.com/Stratio/cassandra-lucene-index]:
> {code}
> SELECT * FROM tweets WHERE lucene='{
>     filter : {type:"range", field:"time", lower:"2014/04/25", upper:"2014/05/1"},
>     query  : {type:"phrase", field:"body", value:"big data gives organizations", slop:1}
> }' 
> {code}
> The {{lucene}} field is a dummy column that has to be added to the table in order to associate the pre-3.0 row-based index with the {{tweets}} table. We could rewrite this query as:
> {code}
> SELECT * FROM tweets 
> WHERE expr(lucene, '{filter : {type:"range", field:"time", lower:"2014/04/25", upper:"2014/05/1"},
>              query  : {type:"phrase", field:"body", value:"big data gives organizations", slop:1}}');
> {code}
> In this version the {{expr}} function takes 2 arguments: the first is the name of the index being targetted, {{lucene}} and the second is the query string itself. 
> Parsing and validation of those expressions would be delegated to the custom index implementations which support them. 
> One thing to consider is index selection. If a query contains custom expressions, but the target index is not selected, C* has no way to use the custom expressions as a post-query filter, like it does with standard expressions & {{ALLOW FILTERING}}. To compensate for that, index selection should be weighted in favour of indexes targetted by custom expressions. At least in the first instance, we should also restrict queries to targetting a single index via custom expressions, i.e. disallow queries like {{SELECT * FROM t WHERE expr(index1, 'foo') AND expr(index2, 'bar')}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)