[jira] [Resolved] (CASSANDRA-5998) Filters

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-5998.
---------------------------------------
    Resolution: Duplicate

UDF is the right way to do this now.

> Filters
> -------
>
>                 Key: CASSANDRA-5998
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5998
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Matt Stump
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> As a counterpart to the functionality provided in triggers it is desirable to filter/mutate query results utilizing a user specified classes. 
> Some example use cases include:
> Row or cell level permissions
> Ad-hoc aggregation or filtering of column values
> Proposed changes include the following:
> * Alter CF metadata to allow the specification of filter classes and options.
> * Modification of the CQL(3) grammar and addition of create/drop filter statements to allow the specification of filter classes.
> * Move cassandara/triggers/CustomClassLoader.java to cassandara/CustomClassLoader.java and use the class loader for both triggers and filters.
> * The addition of the following classes: FilterDefinition, FilterExecuter, and IFilter.
> * Modification of StorageProxy::fetchRows, such that if the CF has a filter specified, rows returned by the result set are run first through the filter which has the authority of either dropping or modifying rows from the result set. If no filter is specified then no filter will be invoked.
> * In order to enable the row/cell level authorization use case StorageProxy::fetchRows must be modified to also require the ClientState. 
> Risks:
> My main concern with the current proposal is that the dependency on ClientState in order to satisfy the cell/row level permissions use case will introduce tight coupling between StorageProxy and ClientState. Another possibility yet to be investigated is to pass ClientState to the filter when the filter class is instantiated.



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