Skip to content

Resource inheritance: pagination on derived types isn't applied #1639

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

Closed
bkoelman opened this issue Nov 26, 2024 · 0 comments · Fixed by #1641
Closed

Resource inheritance: pagination on derived types isn't applied #1639

bkoelman opened this issue Nov 26, 2024 · 0 comments · Fixed by #1641
Labels

Comments

@bkoelman
Copy link
Member

DESCRIPTION

Consider the following resource types:

public sealed class Manufacturer : Identifiable<long>
{
    [HasMany]
    public ISet<Vehicle> Vehicles { get; set; } = new HashSet<Vehicle>();
}

public abstract class Vehicle : Identifiable<long>;

public sealed class Bike : Vehicle
{
    [HasMany]
    public ISet<BicycleLight> Lights { get; set; } = new HashSet<BicycleLight>();
}

public sealed class BicycleLight : Identifiable<long>;

When the following request is executed:

GET /manufacturers/1?include=vehicles.lights

All lights related to the bike are returned, despite the default pagination size of 10.

EXPECTED BEHAVIOR

Pagination is applied to relationships on derived types.

ACTUAL BEHAVIOR

Pagination is not applied.

VERSIONS USED

  • JsonApiDotNetCore version: 5.6.0
  • ASP.NET Core version: 8.0
  • Entity Framework Core version: 8.0
  • Database provider: N/A
@bkoelman bkoelman added the bug label Nov 26, 2024
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
Labels
Development

Successfully merging a pull request may close this issue.

1 participant