[jira] [Updated] (CASSANDRA-6659) Allow "intercepting" query by user provided custom classes

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne updated CASSANDRA-6659:
----------------------------------------

    Attachment: 6659.txt

Attaching fairly trivial patch to implement this (the patch is against 2.0 because that has virtually no chance to break anything existing so why not). Note that the patch remove the pre and post execution hooks from QueryProcessor as those were only here for external tool and, unless I'm missing something obvious, the mechanism here provides a stricly more general mechanism.


> Allow "intercepting" query by user provided custom classes
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-6659
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6659
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>         Attachments: 6659.txt
>
>
> The idea for this ticket is to abstract the main execution methods of QueryProcessor into an interface, something like:
> {noformat}
> public interface QueryHandler
> {
>     public ResultSet process(String query, QueryState state, QueryOptions options);
>     public ResultMessage.Prepared prepare(String query, QueryState state);
>     public ResultSet processPrepared(CQLStatement statement, QueryState state, QueryOptions options);
>     public ResultSet processBatch(BatchStatement statement, QueryState state, BatchQueryOptions options);
> }
> {noformat}
> and to allow users to provide a specific class of their own (implementing said interface) to which the native protocol would handoff queries to (so by default queries would go to QueryProcessor, but you would have a way to use a custom class instead).
> A typical use case for that could be to allow some form of custom logging of incoming queries and/or of their results. But this could probably also have some application for testing as one could have a handler that completely bypass QueryProcessor if you want, say, do perf regression tests for a given driver (and don't want to actually execute the query as you're perf testing the driver, not C*) without needing to patch the sources. Those being just examples, the mechanism is generic enough to allow for other ideas.
> Most importantly, it requires very little code in C*. As for how users would register their "handler", it can be as simple as a startup flag indicating the class to use, or a yaml setting, or both.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)