Repository navigation
Keep field expression keys in patch() and merge() data when building the query (#53) - #342
Merged
Merged
Conversation
lehni
force-pushed
the
fix/rc-json-pure
branch
from
October 12, 2026 20:04
1614d82 to
1420e8d
Compare
lehni
force-pushed
the
fix/rc-json-pure
branch
from
October 12, 2026 21:17
1420e8d to
db15807
Compare
This file contains hidden or 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
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.
What
convertFieldExpressionsToRaw()no longer deletes the field expression keys like'meta:color'from the model ofpatch()andmerge()while it builds the knex query.UpdateOperation.onAfter2()removes them from the patched model once the write has run, after$afterUpdate(), matched by property name likecheckFieldExpressions(). All writes that return or merge their patch model go through it:$query().patch(),patchAndFetch*()and the patches ofupsertGraph().Why
Building the query mutated its data, so building it a second time lost the JSON writes:
toKnexQuery()ortoString()and then running the query, or building aclone()(which shares the model), resolved to 0 without any SQL. The keys were also deleted by their column names, which missed them withsnakeCaseMappers(), so$query().patch({ 'extraMeta:color': 'red' })left anextraMeta:colorproperty on the instance.Breaking
The patched model keeps its field expression keys until the write has run, so instance
$afterUpdate()hooks now see them, as$beforeUpdate()does. A model instance passed topatch()loses them after the write, as before. Running the same query object a second time after it has run still writes no field expressions, as the removal applies to the model it shares with its clones.Tests
In
tests/integration/misc/fieldExpressionKeys.js:patch() should write an undeclared key with a colon to the json path when built before(toKnexQuery()on the query and on a clone first)merge() should write an undeclared key with a colon to the json path when built before$query().patch() should not set the keys with a colon mapped by snakeCaseMappersupsertGraph() should not return the undeclared keys with a colonpatchAndFetchById() should not return the undeclared keys with a colonThe first three fail on
next. TheupsertGraph()test fails with the removal done per operation, as in the first version of this PR. ThepatchAndFetchById()test also passes before the change; it covers the removal for*AndFetch.Part of #53.