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.
To render selectors for derived types, a selector for each non-abstract derived type must be available in
QueryLayer.Selection
, which wasn't the case.Parsing of include chains is changed to include relationships on all concrete derived types.
For example, given an inclusion chain of "wheels" at
/vehicles
, the parser now returnsCar.Wheels
andTruck.Wheels
. This used to beVehicle.Wheels
. There's no point in adding abstract types, because they can't be instantiated in selectors.QueryLayerComposer
was fixed to generate selectors for the left-type of these relationships, instead of for theQueryLayer
resource type (soCar.Wheels
andTruck.Wheels
instead ofVehicle.Wheels
).SelectClauseBuilder
was missing a cast to the derived type when descending into relationship selectors, which is fixed now.Being unable to include relationships of sibling types after a POST/PATCH resource request at a base endpoint was because a
QueryLayer
for fetch-after-post was built against the accurized resource type, and then sent to the original (non-accurized) repository. For example,POST /vehicles?include=TruckRelationship,CarRelationship
only works if the query executes against the non-accurized table (soVehicle
instead ofCar
, becauseCar
doesn't containTruckRelationship
). The fix is to discard the accurized resource type and use the originalTResource
.Other improvements:
SelectClauseBuilder
internally passed along aLambdaScope
that overruled the one present in context, so care had to be taken to use the right one. To eliminate this pitfall, now a new context is forked which contains the appropriateLambdaScope
, so the overruling parameter is no longer needed.Fixes #1639, fixes #1640.
QUALITY CHECKLIST