Details
-
Improvement
-
Status: Resolved
-
Low
-
Resolution: Fixed
-
None
-
None
Description
The idea for this ticket is to abstract the main execution methods of QueryProcessor into an interface, something like:
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);
}
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.