[jira] [Updated] (CASSANDRA-6659) Allow intercepting query by user provided custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6659:
--
Reviewer: Sam Tunnicliffe (was: Benjamin Coverston)
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)
[jira] [Updated] (CASSANDRA-6659) Allow intercepting query by user provided custom classes
[
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)
[jira] [Updated] (CASSANDRA-6659) Allow intercepting query by user provided custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6659:
--
Reviewer: Benjamin Coverston
Tagging [~bcoverston] for review.
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)
