cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6659) Allow "intercepting" query by user provided custom classes
Date Wed, 26 Mar 2014 12:11:15 GMT

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

Sam Tunnicliffe commented on CASSANDRA-6659:
--------------------------------------------

Ok fair enough, I've pushed another commit to my branch that reverts the QP.prepare() changes
& renames the thrift version of getPrepared()

> 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)

Mime
View raw message