-
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
Don't move my cheese! #22202
Merged
Merged
Don't move my cheese! #22202
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AndriySvyryd
approved these changes
Aug 24, 2020
… to weak type Resolves #20729 The issue here was, when adding navigation to weak type, we generate GJ-DIE-SM pattern in which we push current projection to outer element. During the process we updated value buffer indexes for entity projections, some of them were being nested entity projection for weak types. This indexes differed from what it was earlier when the earlier navigation was expanded and put into the tree. Giving us incorrect expression to translate in projection. Fix is to maintain original indexes and add a dummy one if needed. For EntityProjections, each slot would represent reading 1 property value so we can just put the same value in same slot. For non-entity projections, each slot can have complex value. We put this value in whatever next slot is. With projection binding it should bind correctly when translating.
smitpatel
force-pushed
the
smit/bug20729
branch
from
August 24, 2020 21:06
d3db4e0
to
3bc246e
Compare
Hello @smitpatel! Because this pull request has the 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 (
|
ghost
deleted the
smit/bug20729
branch
August 24, 2020 22:34
smitpatel
added a commit
that referenced
this pull request
Nov 12, 2020
Resolves #23285 Now my long paragraph to future contributors to this file This issue reverts the fix from #22202 and fixes it differently. The main issue is that when we generate a LeftJoin through GJ-DIE-SM pattern we need to generate result selector for SM scenario. In this result selector, either we copy VB from source as is and the preserve the inner projection mapping with remapped parameters or we apply projection through the result selector and regenerate bindings for outer. What happened in #22202 that when generating result selector and new bindings, we changed indexes of VB which broke owned navigation mappings. So we fixed that by preserving indexes from entity projections in WeakNavigation expansion scenario. This caused side-effect that now we are applying selector for non-entity projection but preserving VB slots for entity projections. Further we used the read expression to preserve value buffer as is meaning multiple different properties which are in same slot were not preserved correctly causing InvalidCastException while reading. A better approach is to generate result selector accounting for the owned navigations too. Essentially add owned navigation projections to result selector too. This has to happen in both case, when adding LeftJoin in non-owned scenario and in owned scenario. Overall it makes all indexes happy. Thus, harmony in the universe was restored.
smitpatel
added a commit
that referenced
this pull request
Nov 17, 2020
Resolves #23285 Now my long paragraph to future contributors to this file This issue reverts the fix from #22202 and fixes it differently. The main issue is that when we generate a LeftJoin through GJ-DIE-SM pattern we need to generate result selector for SM scenario. In this result selector, either we copy VB from source as is and the preserve the inner projection mapping with remapped parameters or we apply projection through the result selector and regenerate bindings for outer. What happened in #22202 that when generating result selector and new bindings, we changed indexes of VB which broke owned navigation mappings. So we fixed that by preserving indexes from entity projections in WeakNavigation expansion scenario. This caused side-effect that now we are applying selector for non-entity projection but preserving VB slots for entity projections. Further we used the read expression to preserve value buffer as is meaning multiple different properties which are in same slot were not preserved correctly causing InvalidCastException while reading. A better approach is to generate result selector accounting for the owned navigations too. Essentially add owned navigation projections to result selector too. This has to happen in both case, when adding LeftJoin in non-owned scenario and in owned scenario. Overall it makes all indexes happy. Thus, harmony in the universe was restored.
smitpatel
added a commit
that referenced
this pull request
Nov 17, 2020
Resolves #23285 Now my long paragraph to future contributors to this file This issue reverts the fix from #22202 and fixes it differently. The main issue is that when we generate a LeftJoin through GJ-DIE-SM pattern we need to generate result selector for SM scenario. In this result selector, either we copy VB from source as is and the preserve the inner projection mapping with remapped parameters or we apply projection through the result selector and regenerate bindings for outer. What happened in #22202 that when generating result selector and new bindings, we changed indexes of VB which broke owned navigation mappings. So we fixed that by preserving indexes from entity projections in WeakNavigation expansion scenario. This caused side-effect that now we are applying selector for non-entity projection but preserving VB slots for entity projections. Further we used the read expression to preserve value buffer as is meaning multiple different properties which are in same slot were not preserved correctly causing InvalidCastException while reading. A better approach is to generate result selector accounting for the owned navigations too. Essentially add owned navigation projections to result selector too. This has to happen in both case, when adding LeftJoin in non-owned scenario and in owned scenario. Overall it makes all indexes happy. Thus, harmony in the universe was restored.
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Query: InMemory: Preserve value buffer indexes when adding navigation to weak type
Resolves #20729
The issue here was, when adding navigation to weak type, we generate GJ-DIE-SM pattern in which we push current projection to outer element. During the process we updated value buffer indexes for entity projections, some of them were being nested entity projection for weak types. This indexes differed from what it was earlier when the earlier navigation was expanded and put into the tree. Giving us incorrect expression to translate in projection.
Fix is to maintain original indexes and add a dummy one if needed.
For EntityProjections, each slot would represent reading 1 property value so we can just put the same value in same slot.
For non-entity projections, each slot can have complex value. We put this value in whatever next slot is. With projection binding it should bind correctly when translating.