qe: Fix nested objects with $type key in JSON protocol
#4668
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
WASM Size
|
CodSpeed Performance ReportMerging #4668 will not alter performanceComparing Summary
|
✅ WASM query-engine performance won't change substantially (0.985x)Full benchmark reportAfter changes in be1aa17 |
SevInf
force-pushed
the
fix/nested-json-dollar-type
branch
from
4aafb68 to
6f1eab4
Compare
SevInf
pushed a commit
that referenced
this pull request
Jan 24, 2024
Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well.
SevInf
pushed a commit
that referenced
this pull request
Jan 24, 2024
Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well.
SevInf
pushed a commit
that referenced
this pull request
Jan 24, 2024
Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well.
SevInf
pushed a commit
that referenced
this pull request
Jan 26, 2024
Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well.
added 5 commits
January 26, 2024 17:24
In JSON protocol, we use `$type` key as a special marker for the types
that can not be represented in JSON natively. We did not want to make
`$type` identifier reserved, so we took some precautions: if during
encoding, at any point, `$type` key would be seen in user's input we
encode whole object as `{"$type": "Json", "value": [Serialized object] }`.
Engine handled those cases correctly, when `$type: Json` is encountered
at the top level, but not when it is nested. In that case,
`ArgumentValue`-to-`JSON` serialization just picked `value` key and
saved it as a string.
Fixed by moving Json value into it's own kind of `ArgumentValue`, that
are serialized to json as-is.
Fix prisma/prisma#21454
SevInf
force-pushed
the
fix/nested-json-dollar-type
branch
from
dec953d to
5619fe9
Compare
jkomyno
approved these changes
Jan 26, 2024
Weakky
approved these changes
Jan 26, 2024
SevInf
pushed a commit
that referenced
this pull request
Jan 29, 2024
Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well.
SevInf
pushed a commit
that referenced
this pull request
Jan 29, 2024
* qe: Fix nested objects with `$type` key in JSON protocol Introduce another special value to JSON protocol, `"$type": "Raw"`. When encountered, no other nested `$type` keys would be interpreted as special and will be written to DB as is. Main usecase is JSON column values with user-provided `$type` keys. This is an alternative to #4668, that might look cleaner on the engine side. Part of the fix for prisma/prisma#21454, will require client adjustments as well. * Fix & move the test
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.
In JSON protocol, we use
$typekey as a special marker for the typesthat can not be represented in JSON natively. We did not want to make
$typeidentifier reserved, so we took some precautions: if duringencoding, at any point,
$typekey would be seen in user's input weencode whole object as
{"$type": "Json", "value": [Serialized object] }.Engine handled those cases correctly, when
$type: Jsonis encounteredat the top level, but not when it is nested. In that case,
ArgumentValue-to-JSONserialization just pickedvaluekey andsaved it as a string.
Fixed by moving Json value into it's own kind of
ArgumentValue, thatare serialized to json as-is.
Fix prisma/prisma#21454