Filters

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.