-
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: Owned collection should defer translating correlation predicate #18519
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
smitpatel
added a commit
that referenced
this issue
Oct 22, 2019
…on into subuquery Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available. We had logic that if projection contains any columns then projection mapping is already applied to projection. But in above case that is incorrect. That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound. We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type. This scenario does not work for owned/weak types due to #18519 Resolves #18514
smitpatel
added a commit
that referenced
this issue
Oct 22, 2019
…on into subuquery Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available. We had logic that if projection contains any columns then projection mapping is already applied to projection. But in above case that is incorrect. That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound. We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type. This scenario does not work for owned/weak types due to #18519 Resolves #18514
smitpatel
added a commit
that referenced
this issue
Oct 23, 2019
…on into subuquery Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available. We had logic that if projection contains any columns then projection mapping is already applied to projection. But in above case that is incorrect. That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound. We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type. This scenario does not work for owned/weak types due to #18519 Resolves #18514
smitpatel
added
the
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
label
Oct 23, 2019
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
When we expand owned collections in Relational, we convert the correlation predicate to SQL and add it to inner SelectExpression. This SelectExpression contains reference to outer which can be modified during PushDown and we don't have any way to update it. We should generate Where in LINQ and let it get translated to SQL when visiting it so it gets updated reference as necessary.
The text was updated successfully, but these errors were encountered: