gianm opened a new pull request #11959:
URL: https://github.com/apache/druid/pull/11959


   This patch is doing parts 1–3 and 5 from the "Proposed changes" in #11929. 
Nothing is exposed to end users as a result of this patch. It's just changes to 
the planner that enable understanding and authorizing INSERTs, and writing some 
initial tests. The main logic is in **DruidPlanner** and the main tests are in 
**CalciteInsertDmlTest**. Major things you _won't_ find are the ability to 
actually execute INSERT queries (that needs a new QueryMaker) and the ability 
to handle PARTITION BY and CLUSTER BY (that will require parser changes). Those 
would be done in follow-on patches.
   
   The main changes are:
   
   1) DruidPlanner is able to validate and authorize INSERT queries. They 
require WRITE permission on the target datasource.
   
   2) QueryMaker is now an interface, and there is a QueryMakerFactory that 
creates instances of it. There is only one production implementation of each 
(NativeQueryMaker and NativeQueryMakerFactory), which together behave the same 
way as the former QueryMaker class. But this opens the door to executing 
queries in ways other than the Druid query stack, and is used by unit tests 
(CalciteInsertDmlTest) to test the INSERT planning functionality.
   
   3) Adds an EXTERN table macro that allows references external data using 
InputSource and InputFormat from Druid's batch ingestion API. This is not 
exposed in production yet, but is used by unit tests.
   
   4) Adds a QueryFeature concept that enables the planner to change its 
behavior slightly depending on the capabilities of the execution system.
   
   5) Adds an "AuthorizableOperator" concept that enables SqlOperators to 
require additional permissions. This is used by the EXTERN table macro.
   
   Related odds and ends:
   
   - Add equals, hashCode, toString methods to InlineInputSource. Aids in the 
"from external" tests in CalciteInsertDmlTest.
   - Add JSON-serializability to RowSignature.
   - Move the SQL string inside PlannerContext so it is "baked into" the 
planner when the planner is created. Cleans up the code a bit, since in 
practice, the same query is passed in every time to the same planner anyway.


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