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

[5.0.1] Query: Generate predicate correctly when expanding owned collections #23143

Merged
merged 1 commit into from
Nov 17, 2020

Conversation

smitpatel
Copy link
Member

@smitpatel smitpatel commented Oct 29, 2020

Resolves #23130

Some additional tests changed because it ended up causing client eval in the middle due to another level of OwnsMany

Description
Whenever an entity has composite PK and an owned collection, we fail to generate correct correlation predicate to join with table containing owned entities. The incorrect predicate fails during translation throwing an exception.

Customer Impact
Customers cannot use owned collection when owner has composite PK. This can also arise indirect when owned collection entity also contains another owned collection where convention will put composite PK.

How found
Reported by user on RC2

Test coverage
This PR adds coverage for Owned collection targeting owner with composite PK

Regression?
Yes, the scenario worked in 3.1

Risk
Low scenario only affects owned collections when used in actual query.

@smitpatel smitpatel requested a review from a team October 29, 2020 22:16
@smitpatel smitpatel changed the base branch from main to release/5.0 October 30, 2020 21:06
@smitpatel smitpatel changed the title Query: Generate predicate correctly when expanding owned collections [5.0.1] Query: Generate predicate correctly when expanding owned collections Oct 30, 2020
@AndriySvyryd
Copy link
Member

Should we add quirk mode?

@smitpatel
Copy link
Member Author

yes, will do

@smitpatel
Copy link
Member Author

Added the fancy conditional code to get the exception back.

@ajcvickers ajcvickers added this to the 5.0.x milestone Nov 3, 2020
@leecow leecow modified the milestones: 5.0.x, 5.0.1 Nov 3, 2020
@ajcvickers
Copy link
Member

Approved by Tactics for 5.0.1.

Resolves #23130

Some additional tests changed because it ended up causing client eval in the middle due to another level of OwnsMany
@smitpatel smitpatel force-pushed the smit/AvoidRegressionsForJobSecurity branch from 9561370 to c952f4d Compare November 17, 2020 18:16
@ghost
Copy link

ghost commented Nov 17, 2020

Hello @smitpatel!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost
Copy link

ghost commented Nov 17, 2020

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

  1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Give feedback on this
From the bot dev team

We've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments.

Please reach out to us at [email protected] to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin.

@ghost
Copy link

ghost commented Nov 17, 2020

Apologies, while this PR appears ready to be merged, it looks like release/5.0 is a protected branch and I have not been granted permission to perform the merge.

@smitpatel smitpatel merged commit 2174147 into release/5.0 Nov 17, 2020
@smitpatel smitpatel deleted the smit/AvoidRegressionsForJobSecurity branch November 17, 2020 19:41
@ajcvickers ajcvickers removed this from the 5.0.1 milestone Dec 11, 2020
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.

Owned collection when owner has composite PK throws translation failure
5 participants