[ https://issues.apache.org/jira/browse/CASSANDRA-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-10217: --------------------------------------- Fix Version/s: (was: 3.0 beta 2) 3.0.0 rc1 > 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)