Persist Id values into owned collection JSON documents
#34466
Merged
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
|
Did you mean to target |
test/EFCore.Cosmos.FunctionalTests/Query/JsonQueryCosmosTest.cs
Outdated
Show resolved
Hide resolved
AndriySvyryd
approved these changes
Aug 20, 2024
No, I meant to merge into main and backport. I'm still not sure what the bar is or how it will be measured, so I didn't want to be left with another PR I can't merge--looking at you, code cleanup! :-D |
Fixes #29380 There are several aspects to #29380: - Constructor binding (already fixed) - Round-tripping the `Id` property value (addressed by this PR) - Persisting key values in JSON collection documents (tracked by #28594) I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9. To fix the main issue (round-trip `Id`) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using the `Id` property, we treat it like any other property. We then create a shadow `__synthesizedOrdinal` property to act as the ordinal part of the key. We need to discuss: - Is this breaking for any scenario that was working before? - Does this put us in a bad place for the future of owned types with explicit keys?
ajcvickers
added a commit
that referenced
this pull request
Aug 20, 2024
* Persist `Id` values into owned collection JSON documents Fixes #29380 There are several aspects to #29380: - Constructor binding (already fixed) - Round-tripping the `Id` property value (addressed by this PR) - Persisting key values in JSON collection documents (tracked by #28594) I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9. To fix the main issue (round-trip `Id`) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using the `Id` property, we treat it like any other property. We then create a shadow `__synthesizedOrdinal` property to act as the ordinal part of the key. We need to discuss: - Is this breaking for any scenario that was working before? - Does this put us in a bad place for the future of owned types with explicit keys? * Added validation of no explicit keys
ajcvickers
added a commit
that referenced
this pull request
Aug 21, 2024
* Persist `Id` values into owned collection JSON documents Fixes #29380 There are several aspects to #29380: - Constructor binding (already fixed) - Round-tripping the `Id` property value (addressed by this PR) - Persisting key values in JSON collection documents (tracked by #28594) I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9. To fix the main issue (round-trip `Id`) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using the `Id` property, we treat it like any other property. We then create a shadow `__synthesizedOrdinal` property to act as the ordinal part of the key. We need to discuss: - Is this breaking for any scenario that was working before? - Does this put us in a bad place for the future of owned types with explicit keys? * Added validation of no explicit keys
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.
Fixes #29380
There are several aspects to #29380:
Idproperty value (addressed by this PR)I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9.
To fix the main issue (round-trip
Id) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using theIdproperty, we treat it like any other property. We then create a shadow__synthesizedOrdinalproperty to act as the ordinal part of the key.We need to discuss: