Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource inheritance fixes #1641

Merged
merged 3 commits into from
Nov 26, 2024
Merged

Resource inheritance fixes #1641

merged 3 commits into from
Nov 26, 2024

Conversation

bkoelman
Copy link
Member

@bkoelman bkoelman commented Nov 26, 2024

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 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.

QUALITY CHECKLIST

@bkoelman bkoelman force-pushed the resource-inheritance-fixes branch 2 times, most recently from ec809b5 to 4d9266b Compare November 26, 2024 15:51
…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.
- Turn off scanning for vulnerable dependencies in downstream packages
- Turn off warning when targeting NETSTANDARD 1.x
@bkoelman bkoelman force-pushed the resource-inheritance-fixes branch from 4d9266b to cfe159b Compare November 26, 2024 15:54
@bkoelman bkoelman marked this pull request as ready for review November 26, 2024 16:15
@bkoelman bkoelman merged commit 0c79d35 into master Nov 26, 2024
14 checks passed
@bkoelman bkoelman deleted the resource-inheritance-fixes branch November 26, 2024 16:16
Copy link

codecov bot commented Nov 26, 2024

Codecov Report

Attention: Patch coverage is 90.62500% with 9 lines in your changes missing coverage. Please review.

Project coverage is 90.68%. Comparing base (55f671c) to head (cfe159b).
Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
...ies/QueryableBuilding/QueryClauseBuilderContext.cs 50.00% 2 Missing and 1 partial ⚠️
...Core/Queries/QueryableBuilding/QueryableBuilder.cs 40.00% 2 Missing and 1 partial ⚠️
...e/Queries/QueryableBuilding/SelectClauseBuilder.cs 90.32% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1641      +/-   ##
==========================================
- Coverage   90.73%   90.68%   -0.06%     
==========================================
  Files         353      353              
  Lines       11492    11514      +22     
  Branches     1888     1897       +9     
==========================================
+ Hits        10427    10441      +14     
- Misses        696      702       +6     
- Partials      369      371       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant