-
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: we should propagate optional navigations thru nav rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty #7975
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
Found when investigating #7830 |
maumar
added a commit
that referenced
this issue
May 13, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 13, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 13, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 13, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 14, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 15, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 15, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 16, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs).
maumar
added a commit
that referenced
this issue
May 16, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty also fix to #8254 - Null semantics are not carried from subquery Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs). Problem with #8254 was that when eliminating null propagation pattern during SqlTranslation (a != null ? a.Name : null) we were not marking the resulting a.Name as nullable, which then resulted in null semantics not kicking in.
maumar
added a commit
that referenced
this issue
May 18, 2017
…av rewrite, if the initial optional navigation was created using SelectMany-GroupJoin-DefaultIfEmpty also fix to #7761 - Query : Missing null propagation logic for some complex queries with manually created GroupJoin-SelectMany-DefaultIfEmpty also fix to #8254 - Null semantics are not carried from subquery Problem for queries with required navigations that were originating from qsre that was a GroupJoin-SelectMany-DefaultIfEmpty. In those cases, we should be producing LEFT JOINs for the navigations, even though they are required (because initial qsre is already "optional"). We would produce INNER JOINs instead, which would result in data corruption - returning fewer results than expected. Fix is to use more sophisticated logic to determine whether the source qsre is "optional" and therefore we need to expand all its navigations to LOJs. We also apply this logic to MemberAccess and EF.Property, effectively fully protecting against accidental NREs for InMemory and client eval scenarios (we were doing that before only for results of nav rewrite, now we also do it for manually created LOJs). Problem with #8254 was that when eliminating null propagation pattern during SqlTranslation (a != null ? a.Name : null) we were not marking the resulting a.Name as nullable, which then resulted in null semantics not kicking in.
fixed in bb7eebd |
maumar
added
the
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
label
May 18, 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
Repro:
This produces the following sql:
Instead we should detect that organization is optional created via SelectMany-GroupJoin-DefaultIfEmpty and create LEFT JOIN instead
The text was updated successfully, but these errors were encountered: