Reduce complexity of QueryLayer after composition #1735
Merged
+62
−39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attempts to address the slow query performance reported in #1731.
The reported issue involves a type hierarchy that includes two nested includes for each type in the hierarchy. The number of rows in the type hierarchy is high (various kinds of products), whereas the two nested includes (unit group and unit) are small. Because pagination is applied at every level by default, the SQL query becomes very complex. This can be fixed by disabling pagination in the two nested includes via resource definitions.
This PR simplifies the query using the following changes:
This reduces the query for
/PriceGroup?include=products.unitGroup.units
from:to:
However, this doesn't entirely solve all problems. But so far, I think it's the best we can offer. Because it's not possible to express a selector at a base level.
For example, using the following model:
The following query is produced without any parameters (so all pagination turned off):
But when a parameter is specified somewhere in the type hierarchy (for example,
fields
forDerived1
), we MUST always select the actual type:It is not possible to apply this on a base type (for example,
fields
forConcreteBase
):Thus, the only way to make that work is to expand into separate selectors for
ConcreteBase
and all of its derived types in the type hierarchy:QUALITY CHECKLIST