Details
-
New Feature
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
Description
(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:
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}
}'
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:
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}}');
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')