Skip to content
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

[6.0.2] Query: Defer inline-ing owned navigation expansion till all joins are generated #26617

Merged
merged 1 commit into from
Dec 15, 2021

Conversation

smitpatel
Copy link
Member

@smitpatel smitpatel commented Nov 10, 2021

Issue: Expanding owned navigations in relational falls into 3 categories

  • Collection navigation - which always generates a subquery. The predicate is generated in LINQ to allow mutation of outer SelectExpression
  • Reference navigation sharing table - which picks column from same table without needing to add additional join. This only mutate the projection list for SelectExpression at subquery level
  • Reference navigation mapped to separate table - which generates additional joins. Generating join can cause push down on outer SelectExpression if it has facets (e.g. limit/offset). This pushdown causes owned expansion from category 2 to be outdated and invalid SQL since they get pushed down to subquery. While their relevant entity projection is updated inside SelectExpression we already inlined older object in the tree at this point.

In order to avoid issue with outdated owned expansion, we defer actual inline-ing while processing owned navigations so that all navigations are expanded (causing any mutation on SelectExpression) before we inline values.

This PR introduces DeferredOwnedExpansionExpression which remembers the source projection binding to SelectExpression (which will remain accurate through pushdown), and navigation chain to traverse entity projections to reach entity shaper for final owned navigation. This way, we get up-to-date information from SelectExpression after all joins are generated.
We also find updated entity projection through binding after we generate a join if pushdown was required.

Resolves #26592

The issue was also present in 5.0 release causing non-performant SQL rather than invalid SQL. During 5.0 we expanded owned navigations again while during client eval phase (which happens in customer scenario due to include). This caused to earlier owned reference to have correct columns. Though the entity projection for owner was changed due to pushdown so we didn't add latter reference navigation binding in correct entity projection causing us to expand it again during 2nd pass.

The exact same issue doesn't occur for InMemory provider (due to slightly different implementation) though we should also make InMemory provider work this way, which we can do in 7.0.

Description

In a query if owned reference navigations mapped to separate tables are expanded at different time with a subquery causing operation in between (like skip/take/distinct), then the columns of already expanded reference navigation are incorrect.

Customer impact

Query with such scenario will generate invalid SQL causing an exception.

How found

Customer reported on 6.0 package.

Regression

Partially. If the query doesn't have any form of client eval then it fails in 5.0 with same error. If it has client eval then it translated in 5.0 with inefficient SQL.

Testing

Added test for the scenario. Also there are existing tests to validate expansion working correctly in usual cases.

Risk

Medium. This PR changes how owned navigations are expanded in relational layer. While we have good test coverage, this is still significant impact code path. We have added quirk in order to revert to previous behavior if any issue arises.

@smitpatel smitpatel requested review from ajcvickers and a team November 10, 2021 23:30
@smitpatel smitpatel modified the milestone: 6.0.x Nov 10, 2021
@smitpatel smitpatel force-pushed the smit/patchysnow2 branch 2 times, most recently from 3c9222b to b80e291 Compare November 11, 2021 16:19
Copy link
Member

@roji roji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are some nits, I don't have enough grasp of this area to fully grok everything - but it seems to make sense to me.

@@ -1208,179 +1212,459 @@ protected override Expression VisitExtension(Expression extensionExpression)

private Expression? TryExpand(Expression? source, MemberIdentity member)
{
source = source.UnwrapTypeConversion(out var convertedType);
if (source is not EntityShaperExpression entityShaperExpression)
if (_useOldBehavior)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quirk nit: maybe consider just quirking the two (?) sites where things actually changed, rather than duplicating the entire code (would make the diff seem easier to review and much less menacing 😉). If not, maybe consider renaming the method TryExpandOld and leaving as-is, and have a new TryExpand which calls into it if _useOldBehavior.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried the first way but there were multiple sites and certain variables which occur only in one path. I split with if so that it is also easier to see what is the final code and easier to merge to release.
https://github.com/dotnet/efcore/pull/26617/files?w=1 should remove old path indentation diff.

@AndriySvyryd AndriySvyryd added this to the 6.0.x milestone Nov 11, 2021
@jamshedd
Copy link
Member

Risk is M rather than low so fix in main and wait to see more reports.

@smitpatel smitpatel marked this pull request as draft November 11, 2021 20:37
@smitpatel smitpatel removed this from the 6.0.x milestone Nov 11, 2021
@smitpatel smitpatel closed this Nov 11, 2021
@ChristopherHaws
Copy link
Contributor

Is this really medium risk? This issue is going to probably require us to downgrade our application from .NET 6 to .NET 5. =/

@smitpatel smitpatel reopened this Dec 8, 2021
… generated

Issue: Expanding owned navigations in relational falls into 3 categories
- Collection navigation - which always generates a subquery. The predicate is generated in LINQ to allow mutation of outer SelectExpression
- Reference navigation sharing table - which picks column from same table without needing to add additional join. This only mutate the projection list for SelectExpression at subquery level
- Reference navigation mapped to separate table - which generates additional joins. Generating join can cause push down on outer SelectExpression if it has facets (e.g. limit/offset). This pushdown causes owned expansion from category 2 to be outdated and invalid SQL since they get pushed down to subquery. While their relevant entity projection is updated inside SelectExpression we already inlined older object in the tree at this point.

In order to avoid issue with outdated owned expansion, we defer actual inline-ing while processing owned navigations so that all navigations are expanded (causing any mutation on SelectExpression) before we inline values.

This PR introduces DeferredOwnedExpansionExpression which remembers the source projection binding to SelectExpression (which will remain accurate through pushdown), and navigation chain to traverse entity projections to reach entity shaper for final owned navigation. This way, we get up-to-date information from SelectExpression after all joins are generated.
We also find updated entity projection through binding after we generate a join if pushdown was required.

Resolves #26592

The issue was also present in 5.0 release causing non-performant SQL rather than invalid SQL. During 5.0 we expanded owned navigations again while during client eval phase (which happens in customer scenario due to include). This caused to earlier owned reference to have correct columns. Though the entity projection for owner was changed due to pushdown so we didn't add latter reference navigation binding in correct entity projection causing us to expand it again during 2nd pass.

The exact same issue doesn't occur for InMemory provider (due to slightly different implementation) though we should also make InMemory provider work this way, which we can do in 7.0.
@smitpatel smitpatel marked this pull request as ready for review December 8, 2021 18:13
@smitpatel smitpatel changed the title [6.0.1] Query: Defer inline-ing owned navigation expansion till all joins are… [6.0.2] Query: Defer inline-ing owned navigation expansion till all joins are… Dec 8, 2021
@smitpatel smitpatel requested review from roji, maumar and a team December 8, 2021 18:16
@AndriySvyryd AndriySvyryd changed the title [6.0.2] Query: Defer inline-ing owned navigation expansion till all joins are… [6.0.2] Query: Defer inline-ing owned navigation expansion till all joins are generated Dec 8, 2021
@AndriySvyryd AndriySvyryd added this to the 6.0.x milestone Dec 10, 2021
@leecow leecow modified the milestones: 6.0.x, 6.0.2 Dec 14, 2021
@ajcvickers ajcvickers merged commit d659dd8 into release/6.0 Dec 15, 2021
@ajcvickers ajcvickers deleted the smit/patchysnow2 branch December 15, 2021 09:26
@ajcvickers ajcvickers removed this from the 6.0.2 milestone Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants