-
-
Notifications
You must be signed in to change notification settings - Fork 158
Support for query parameters on nested/deep resource endpoints #627
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
Comments
I think the malfunctioning of paging, inclusion and sparse field (and probably the rest of the query parameters too) for nested resources have a common origin. Thanks for pointing this out |
I looked into this and unfortunately this is all pretty complicated IncludeThis was easy to support and is addressed in #634 FilterDoing a filter on nested resource routes essentially the same as performing a EF Core filtered include which is not possible. Eg the following request
would be translated to the currently not supported EF Core invocation dbContext.People.Include(e => e.Tags.Where(t => t.Name.Contains("jsonapi"))); See the temp work around paragraph all the way at the bottom of this comment how this can be achieved in-memory without using custom repositories. PagingI suspect this is also not possible, see the following passage (source)
Note that this is about EF, but if it wasn't supported in EF that is a good indicator that it isn't supported in EF Core either. I need to research this further to be sure, but even if it turns out that EF Core works smoothly with it, the same issue as with sparse field selection and sorting will be encountered (next paragraph). Field selection, sortingI think it is feasible to build expression trees that perform a sql We could go ahead and change the expression tree building to be more flexible and support this. But from a separation-of-concerns point of view, I don't think having the Temporary work around: in-memoryNevertheless: paging, field selection, sort and even (included) filtering can be supported in-memory to ensure consistency in the API response. I'm currently pretty busy with other stuff but this definitely is high up in the backlog. I think currently a developer could already implement this themselves by accessing the query parameter services in a For an example on how to do a filtered include using hooks see the example in the hooks docs. You would have to adjust this to be executed conditionally depending on the state of the For now I have changed the API to be explicit about this not being supported by returning a HTTP 400 Bad Request for unsupported query parameters, see #634. |
First of all, thanks for putting effort in this. I can image these things are hard to get right. But I'm surprised (and concerned) to find out these nested scenarios were never supported. This is what I expected the library to excel in: auto-generating smart SQL queries over relationships in various directions with unconstrained depth, based on the model/graph. Not having these features makes me doubt whether adopting this library for us is even an option. I expected the library to translate a request to:
into:
because
and I expected the library to generate the same SQL statement for both of them. I am not interested in the proposed in-memory workaround. And would recommend against it, because it creates false expectations. Better not have it, than remove it in vNext because it was never properly implemented and upset existing users. I get that you are trying to finalize for the v4 release and a change like this involves a lot of effort and causes risk. However if this remains unsupported, it would help others to mention these limitations in the documentation. |
Currently the library identifies db.Article.Include(a => a.Tags).Where(a => a.Id.Equals(1) && a.Tags.Any( t => t.Name.Equals("jsonapi"))); Which is a bit more tedious to build with expression trees, and rapidly becomes unmanageable when filtering on more deeply included resources. I think if we were to identify
Unfortunately this is still not a small fix: treating
I believe this is currently beyond the scope of JADNC: it does not aim to extend EF Core but rather to provide elimination of boilerplate code (for among which it uses EF Core). Filtered includes have been put on the roadmap for 5.0.0 so for generic, unconstrained usage I would prefer to wait for their support. But nevertheless it seems we could support it two levels deep using expression tree building. I will further scope the size of this task in the course of this/next week. But note that the size of the list of feedback is growing faster than I can currently process (i.e. you are more than welcome to make a draft for this 🚀) |
I've been thinking about this some more and did some experiments. I discovered that my expectations on relationships of unconstrained depth were based on wrong assumptions and me not understanding the full story. I found that relationship requests only go one level deep at most. So there is no such thing as I also realized that an endpoint like Then I tried to patch up parts of the library to transform requests to My current workaround for the deep paging/filtering limitations is to perform a HTTP redirect in cases like |
Such redirect feature sounds like a very interesting feature to add. Feel free to hit me up on our gitter channel if you would like to have a more direct communication line with me to address questions about JADNC internals |
Oh jeez, that's interesting. We'll have to do a lot of refactoring and improvements once this lands |
Replaced by #751, |
Description
For example, the URL:
https://localhost:5001/api/users/123/orders?fields[orders]=purchase-date
returns all attributes of orders, instead of only purchase-date.
The text was updated successfully, but these errors were encountered: