QueryPlan lets you inspect and efficiently fetch the data a ViewModel will need, and is for developers diagnosing data-loading behavior in MDriven Designer and Turnkey.

What QueryPlan does

A QueryPlan analyzes a ViewModel to determine which objects, classes, relations, and values the view can use. MDriven uses that information to fetch required data in groups rather than allowing the user interface to trigger many individual lazy fetches.

A lazy fetch retrieves an object when an object locator needs it. Lazy fetching can be useful for an isolated object, but it performs poorly when rendering a view causes many objects to be fetched one at a time. Each individual fetch can require a server round trip. QueryPlan reduces this N+1-query pattern by identifying data requirements before the view needs each individual value.

For example, a ViewModel may show a selected customer and a nested list of that customer's orders. If each order row also displays related information, fetching that information separately as every row is drawn can result in many fetches. QueryPlan identifies the types of data used by the hierarchy and its columns so that MDriven can fetch data efficiently for the displayed objects.

How QueryPlan builds and uses a plan

QueryPlan has both a static and a runtime role.

Static analysis

QueryPlan analyzes the ViewModel structure in two stages:

1. It analyzes hierarchy-building expressions: the nestings that define the ViewModel tree. At this stage it collects the classes and relations involved, plus classes used by expressions with the allinstances operator.
2. It analyzes expressions used by non-nesting columns.

Together, these stages describe the type of information that may be used at each hierarchy level. The result is a static plan of what the ViewModel can require; it is not a fixed list of objects to retrieve in every situation.

Runtime response to selection changes

Views can change the objects they display after they are created. This commonly happens in a seeker, where a newly selected object becomes the root for details shown below it. A nesting can also be based on a variable.

To handle these changes, QueryPlan subscribes to the vCurrent variables for nesting levels. When a vCurrent value changes, QueryPlan can fetch the required data beneath that point before UI rendering falls back to lazy fetching.

For example:

• A seeker produces a new list of customers.
• The user selects one customer.
• That customer becomes the current object for a detail hierarchy.
• QueryPlan evaluates the applicable part of the plan and fetches the details needed below that customer.

If the view is not acting as a seeker, the needed data may already be present. In that case, QueryPlan detects that no unseen objects are required and does not perform an additional fetch.

Inspect the static QueryPlan

Use MDriven Designer to see the QueryPlan tree that MDriven derives from a ViewModel.

1. Open the ViewModel in MDriven Designer.
2. Right-click the ViewModel's main class.
3. Select Extras and then QueryPlan.
4. Paste the clipboard contents into a text editor.
5. Review the report to see what the QueryPlan tree identifies for the ViewModel.

Use this report when a ViewModel fetches more data than expected or when you need to verify whether a nesting, relation, or expression is visible to static analysis.

Debug QueryPlan execution

The static report shows what QueryPlan can see. The debugger log shows what happens when a ViewModel is actually fetched.

1. Open the debugger.
2. Select the Logging tab.
3. Enable PMapper logging.
4. Set an object to use as the ViewModel root.
5. On the Result as root for ViewModel tree tab, select the ViewModel you want to analyze.
6. Trigger the ViewModel fetch.
7. Review the PMapper log entries to follow QueryPlan activity.

The log includes entries such as:

Log entry	Meaning
QPlap	The QueryPlan processing lap, or stage, in which the entry occurred.
START Hierarchy	QueryPlan starts loading the ViewModel hierarchy structure and fetching its links.
QPlap START Columns	QueryPlan starts processing column requirements and the following individual links.

When diagnosing a seeker, repeat the test after changing the selected object. This shows whether the changed vCurrent causes QueryPlan to fetch the details required by the newly selected root.

QueryPlan data in Turnkey

When you debug in Turnkey, the end of the debug page shows the QueryPlan levels that executed. Use these levels together with the PMapper log to compare the plan that ran with the ViewModel interaction that triggered it.

Persistence-mapper limitation

The XML persistence mapper does not use the multi-expression fetcher. Multi-expression fetching is a feature of MDrivenServer. When evaluating QueryPlan behavior, account for the persistence mapper in use; diagnostics and expected fetch behavior can differ from an MDrivenServer-backed application.

Related OCL behavior

ExecuteQueryPlan is an OCL operation that executes OCL logic while observing missing data, fetching that data in bulk, and continuing execution. Use that page for the operator syntax and its execution behavior. QueryPlan on this page concerns the ViewModel analysis and fetching strategy used to avoid repeated lazy fetches while a view is displayed.

See also

• Documentation:OCLOperators ExecuteQueryPlan
• Documentation:Working with Code and Persistence Mapping
• Documentation:Showing data