Resource inheritance: can't include derived types after create resource #1640
Labels
Comments
bkoelman
added a commit
that referenced
this issue
Nov 26, 2024
…ct 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 returns `Car.Wheels` and `Truck.Wheels`. This used to be `Vehicle.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 the `QueryLayer` resource type (so `Car.Wheels` and `Truck.Wheels` instead of `Vehicle.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 (so `Vehicle` instead of `Car`, because `Car` doesn't contain `TruckRelationship`). The fix is to discard the accurized resource type and use the original `TResource`. Other improvements: - During the process of building expression trees, consistency checks have been added to prevent downstream crashes that are difficult to diagnose. - `SelectClauseBuilder` internally passed along a `LambdaScope` 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 appropriate `LambdaScope`, so the overruling parameter is no longer needed. Fixes #1639, fixes #1640.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DESCRIPTION
Using the models described in #1639, the following request:
fails with status 500 (Internal Error):
{ "links": { "self": "http://localhost/vehicles?include=lights" }, "errors": [ { "id": "84b108ae-c1a7-4eaa-9b96-3f239a5c2201", "status": "500", "title": "An unhandled error occurred while processing this request.", "detail": "Property 'System.Collections.Generic.ISet`1[Models.BicycleLight] Lights' is not defined for type 'Models.Vehicle' (Parameter 'property')" } ], "included": [] }EXPECTED BEHAVIOR
No error, the response includes the related resources.
ACTUAL BEHAVIOR
Crash.
VERSIONS USED
The text was updated successfully, but these errors were encountered: