QueryPlan is the ability to statically analyze a ViewModel to know ahead of time what data it will use. It is used to efficiently fetch the data for a view.
Since views may shift what data they show (seekers or when base nesting on variables), the QueryPlan logic is active even after view creation - to make sure the slow-performing lazy fetch does not kick in.
Lazy fetch is a strategy to fetch the object needed for an object locator just in time. This is practical but if every object would fetch itself with a roundtrip to the server, the application would not scale at all.
QueryPlan has multiple steps:
- Statically figure out the Hierarchy building expressions (the nestings). On this level, we only collect Class and Relation + the classes that expressions used the allinstances operator on
- Statically figure out what the other columns use (the non-nestings)
From these two steps, we have static information about what TYPE of information will - at one point or another - be used by the view - per hierarchy level.
QueryPlan places a subscription on all vCurrent variables for Nesting levels. Whenever a vCurrent variable is shifted, it may be an opportunity for QueryPlan to efficiently fetch data below this point.
This happens, for example, in seekers, when a user has a new list of objects and the selected object may be root to show details. In this case, QueryPlan will kick in and efficiently fetch such details for the selected object.
If your View is not a seeker in any form, the data is already fetched and QueryPlan should discover that no unseen objects are requested - and thus no fetch is needed.
Understanding the Query Planner
Static Plan
Right-click on the ViewModel main class and then select Extras and QueryPlan.
That will place a text block in the clipboard with a report on what the QP tree sees.
Viewmodel scope and expressions
See Analyze ViewModel classes and expressions for more information.
QP data in turnkey when debugging
At the end of the debug page, you can see the executed QP levels.
Debugging QueryPlan execution
You can see the QP log in the debugger. On the tab "Logging", turn on the PMapper to see QP log entries.
Usually, after turning on the log, set an object and pick the ViewModel you want to analyze in the tab "Result as root for ViewModel tree". The fetch of the ViewModel runs and you will get a log of how the QP fetches the ViewModel.
Explanation of the log content:
QPlap => in which process stage/lap the QP is
START Hierarchy => start of the QP's loading of ViewModel structure fetching links
QPlap START Columns => start of following single links
Note: The XML persistence mapper doesn't use the multi-expression fetcher - it is a feature of the MDrivenServer.
Keywords
Query optimizer, Query planner, optimise, ViewModel optimiser