You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Henry Manasseh (JIRA)" <ji...@apache.org> on 2016/03/29 22:56:25 UTC

[jira] [Commented] (CASSANDRA-11458) Complete support for CustomExpression

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

Henry Manasseh commented on CASSANDRA-11458:
--------------------------------------------

I can provide a patch for this. I have done the changes locally. Who needs to approve this change?

> Complete support for CustomExpression
> -------------------------------------
>
>                 Key: CASSANDRA-11458
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Henry Manasseh
>            Priority: Minor
>         Attachments: Custom-expression-Change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way to implement queries making use of the "exp('index', 'value)" syntax due to the fact CustomExpression is declared as final and there is no way to for developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can extend and create their own subclass and provide their own isSatisfiedBy operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override isSatisfiedBy method with their logic (public boolean isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib directory along with a secondary index class which overrides Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained if the developer does not provide a custom class in the create index options.



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