cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6659) Allow "intercepting" query by user provided custom classes
Date Wed, 05 Feb 2014 19:06:09 GMT

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

Mime
View raw message