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

Don't move my cheese! #22202

Merged
1 commit merged into from
Aug 24, 2020
Merged

Don't move my cheese! #22202

1 commit merged into from
Aug 24, 2020

Conversation

smitpatel
Copy link
Contributor

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.

@smitpatel smitpatel requested a review from a team August 24, 2020 20:49
… 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.
@ghost
Copy link

ghost commented Aug 24, 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 ghost merged commit 3fea2a2 into release/5.0 Aug 24, 2020
@ghost 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Misinterpreted expression with owned entities
2 participants