[
https://issues.apache.org/jira/browse/CASSANDRA-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939437#comment-13939437
]
Sam Tunnicliffe commented on CASSANDRA-6659:
--------------------------------------------
[~slebresne] I've made a couple of extensions to your original patch & pushed
the results to https://github.com/beobal/cassandra/commits/6659
The first commit there is your original patch, there are 2 relevant additions
in the second commit:
* Made QueryProcessor.processStatement public, so that QueryHandler
implementations can call it from within their process implementations.
Otherwise all the QH implementation has to work with is the original CQL
String. If it wants access to the parsed CQLStatement, it can call
QP.getStatement, but it has to delegate to QP.process to actually execute it,
meaning double the parsing overhead.
* Extended the QH interface so that it is also usable for CQL3 queries received
over thrift (this also involved a slight refactoring of QP.prepare)
While I was at it I also cleaned up a couple of things in QP (removed the hooks
imports, dropped some unused arguments etc) and removed the now unused classes
> 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.2#6252)
