-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Verify exceptions when Include() is used in invalid or not supported locations in a query #14671
Comments
Above code restricts include to specified only on queryables which represent an entityType except for using Select (or SelectMany in future). |
We don't throw for queries where include comes after identity projection, or simple SelectMany. ss.Set<Faction>().Select(f => f).Include(h => h.Capital) ss.Set<Faction>().SelectMany(f => f.Capital.BornGears).Include(g => g.Squad) |
maumar
added a commit
that referenced
this issue
Oct 2, 2019
maumar
added a commit
that referenced
this issue
Oct 2, 2019
maumar
added a commit
that referenced
this issue
Oct 2, 2019
There are test disabled with this. If we decide to close this, we should clean up |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some time ago we discussed in #9030 the possibility of throwing an exception by default when we find an Include() call that has to be ignored.
We decided against switching to throw by default because there are legitimate situations in which after a valid Include() is added to a query, further composition makes the Include() unnecessary, and we definitively don't want to throw in those situations. A common example of this is adding a call to Count() at the end of a query to compute the number of rows the original query will return.
However there is another situations in which Include() is called in a location which we either consider invalid or unsupported in a given release.
I am creating this issue to consider distinguishing between these situations and ensuring that we throw for the later.
I believe this aligns well with the philosophy of our query design in 3.0, in that it can help customers detect things that won't work earlier in development.
It can also help us evolve support for Include() in the new query pipeline more intentionally: we can start with support for basic scenarios in 3.0 and gradually add support for additional scenarios based on customer feedback, and with less risk of introducing breaking changes.
I also think addressing #12737 (revisit interpretation of path passed to Include() to allow partial matches) should help in reducing the number of situations in which Include() appears to be needed in weird locations in a query.
The text was updated successfully, but these errors were encountered: