-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Query: Contains on element coming from optional navigation doesn't get server-evaluated #6937
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-bug
Milestone
Comments
maumar
changed the title
Invalid LINQ expression generated (InvalidOperationException)
Query: Contains on element coming from optional navigation doesn't get server-evaluated
Nov 11, 2016
maumar
added a commit
that referenced
this issue
Nov 11, 2016
…tion doesn't get server-evaluated Problem was that when trying to translate contains ResultOperator we assumed that the translatable expression would always be member access or a EF.Property method call. However in some cases (e.g. when item is part of an optional navigation) this is not the case, and the underlying member/EF.Property is wrapped around Convert and/or NullConditional. Fix is to perform translation on the item before before checking what shape it is. This simplifies the code and protects from similar situations, because SqlTranslatingExpressionVisitor already optimizes out a lot of redundant nodes in the expression tree.
maumar
added a commit
that referenced
this issue
Nov 11, 2016
…tion doesn't get server-evaluated Problem was that when trying to translate contains ResultOperator we assumed that the translatable expression would always be member access or a EF.Property method call. However in some cases (e.g. when item is part of an optional navigation) this is not the case, and the underlying member/EF.Property is wrapped around Convert and/or NullConditional. Fix is to perform translation on the item before before checking what shape it is. This simplifies the code and protects from similar situations, because SqlTranslatingExpressionVisitor already optimizes out a lot of redundant nodes in the expression tree.
maumar
added a commit
that referenced
this issue
Nov 14, 2016
…tion doesn't get server-evaluated Problem was that when trying to translate contains ResultOperator we assumed that the translatable expression would always be member access or a EF.Property method call. However in some cases (e.g. when item is part of an optional navigation) this is not the case, and the underlying member/EF.Property is wrapped around Convert and/or NullConditional. Fix is to perform translation on the item before before checking what shape it is. This simplifies the code and protects from similar situations, because SqlTranslatingExpressionVisitor already optimizes out a lot of redundant nodes in the expression tree.
maumar
added a commit
that referenced
this issue
Nov 15, 2016
…tion doesn't get server-evaluated Problem was that when trying to translate contains ResultOperator we assumed that the translatable expression would always be member access or a EF.Property method call. However in some cases (e.g. when item is part of an optional navigation) this is not the case, and the underlying member/EF.Property is wrapped around Convert and/or NullConditional. Fix is to perform translation on the item before before checking what shape it is. This simplifies the code and protects from similar situations, because SqlTranslatingExpressionVisitor already optimizes out a lot of redundant nodes in the expression tree.
Fixed in 8965903 |
maumar
added
the
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
label
Nov 15, 2016
@maumar - thank you! |
divega
added
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
and removed
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
labels
May 10, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-bug
I'd like to help fix this, but if there's a workaround or suggested different way to express the same query that might work to get me around this in the short term, I'd be very grateful. Any workaround suggestions are welcome!
Steps to reproduce
Build a query with the following:
Relevant entity models:
The issue
First issue is I get a warning that the
Contains(b.WidgetsUsage.Brick.Texture.Id)
cannot be translated to a store expression. I think this should be fine/possible - certainly it works with another very similar query clause. In that case I think the only difference is there's aSelectMany
involved: replace one Texture with multiple Colours:set = set.Where(i => !i.UsedWidgets.SelectMany(b => b.WidgetUsage.Widget.Colours).Select(c => c.ColourId).All(c => query.colours.ids.Contains(c)));
.The second issue is, LINQ generation exception!
Exception:
Stack trace:
My LINQ expression
DebugView
:Further technical details
EF Core version:
1.1.0-preview1-*
Operating system:
Windows 10
Visual Studio version: n/a (
dotnet
, 1.1 Preview 1)The text was updated successfully, but these errors were encountered: