Draft implementation for cross-db query plan execution. #551
Conversation
|
|
||
| full_query_args = dict(query_args) | ||
|
|
||
| plan_and_depth = _get_plan_and_depth_in_dfs_order(query_plan_descriptor.root_sub_query_plan) |
There was a problem hiding this comment.
Does the code below depend on the order being a dfs order? In some very trivial cases we will have to start execution from the leafs. Just making sure we don't lock ourselves out from that execution plan with the code structure.
There was a problem hiding this comment.
One thing we should document better than we currently have is the distinction between the output of split_query() and the output of make_query_plan() -- I think that would clarify the situation here. split_query() tells us where we cross schemas, but does not specify an execution order. make_query_plan() specifies an order between the subqueries, and is free to specify any valid order -- and may choose an optimized order if it has access to statistics etc.
Given that, once a query plan is made, it's always executed from the root onward. We may in the future allow different styles of executors (e.g. DFS, BFS, async + parallel across children, etc.), but this executor function is just a simple sync DFS.
…/graphql-compiler into query_plan_execution
Codecov Report
@@ Coverage Diff @@
## main #551 +/- ##
==========================================
- Coverage 94.36% 93.54% -0.83%
==========================================
Files 113 113
Lines 9065 9168 +103
==========================================
+ Hits 8554 8576 +22
- Misses 511 592 +81
Continue to review full report at Codecov.
|
Not ready to merge. Please look at it for big-picture design issues and not small nits.
There's a bunch of debugging code currently in there as well, since it has no unit tests and we have no cross-db integration tests, and I've been testing it by hand instead.