paul-rogers opened a new pull request, #12637:
URL: https://github.com/apache/druid/pull/12637

   Druid has traditionally supported just one kind of SQL statement: `SELECT`. 
The planner was thus designed to process "a query", and an ever-increasing 
amount of conditional code was added to support other statements such as 
`INSERT` and `REPLACE`. As we look toward adding DDL statements, the current 
approach will become unworkable. Other SQL products introduce an additional 
layer to handle statement types: the *statement handler*. This PR adds 
statement handlers to Druid.
   
   This PR builds on the [single-pass 
planner](https://github.com/apache/druid/pull/12636) PR to heavily refactor the 
Druid planner to split statement-specific code into a set of statement-specific 
handler classes. All handlers implement a simple interface:
   
   ```java
   interface SqlStatementHandler
   {
     void analyze() throws ValidationException;
     Set<ResourceAction> resourceActions();
     PrepareResult prepare() throws RelConversionException, ValidationException;
     PlannerResult plan() throws SqlParseException, ValidationException, 
RelConversionException;
   }
   ```
   
   The details of what is needed for each statement is a (complex) 
implementation detail of the handler classes.
   
   At present, all the SQL statements which Druid supports include a `SELECT`: 
`EXPLAIN`, `INSERT`, `REPLACE` and, of course, `SELECT` itself. To reflect this 
fact, a base `QueryHandler` class handles the common aspects. As we add other 
statements (such as DDL), completely new handlers will handle those cases.
   
   For the most part, the code is identical between `master` and this PR, but 
the code is heavily refactored and shifted around.
   
   The key risk with this kind of change is that we break something. To catch 
any regression, this work was done in a private branch that also had the 
[planner test framework](https://github.com/apache/druid/pull/12545). The 
planner artifacts (schema, logical plan, native query) were identical before 
and after the change. The various `Calcite?QueryTest` cases provide a lighter 
validation in this PR itself, since the planner framework is not yet in master, 
nor is it included in this PR.
   
   Since the PR incorporates #12636, we should review and merge that PR first. 
I'll then rebase this one on the updated master which will remove the common 
code, leaving only the handler-related changes.
   
   <hr>
   
   This PR has:
   - [X] been self-reviewed.
   - [X] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [X] added comments explaining the "why" and the intent of the code 
wherever would not be obvious for an unfamiliar reader.
   - [X] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   - [ ] been tested in a test Druid cluster.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to