Resource inheritance fixes #1641
Merged
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.WheelsandTruck.Wheels. This used to beVehicle.Wheels. There's no point in adding abstract types, because they can't be instantiated in selectors.QueryLayerComposerwas fixed to generate selectors for the left-type of these relationships, instead of for theQueryLayerresource type (soCar.WheelsandTruck.Wheelsinstead ofVehicle.Wheels).SelectClauseBuilderwas 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
QueryLayerfor 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,CarRelationshiponly works if the query executes against the non-accurized table (soVehicleinstead ofCar, becauseCardoesn't containTruckRelationship). The fix is to discard the accurized resource type and use the originalTResource.Other improvements:
SelectClauseBuilderinternally passed along aLambdaScopethat 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