-
Notifications
You must be signed in to change notification settings - Fork 192
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
Storage: Add extend_json
Tag for Enhanced JSON Field Handling in bulk_update
Operations
#6659
base: main
Are you sure you want to change the base?
Conversation
for more information, see https://pre-commit.ci
… bulk-update-json
for more information, see https://pre-commit.ci
… bulk-update-json
If some test hang up, it might benefit from #6674. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6659 +/- ##
==========================================
- Coverage 78.00% 76.60% -1.39%
==========================================
Files 563 563
Lines 41766 41812 +46
==========================================
- Hits 32574 32025 -549
- Misses 9192 9787 +595 ☔ View full report in Codecov by Sentry. |
It seems the pytest hangs somewhere again. If we know which one is hang and can reproduce locally, I think I know how to debug it if it is the RMQ problem. |
In #6587, it was determined that when performing
bulk_update
operations on JSON fields likeextra
, the existing JSON should be extended rather than overwritten. To address this, this PR introduces a new tag,extend_json
, that controls howbulk_update
handles JSON fields. By default,extend_json
is set toFalse
, ensuring backward compatibility. When explicitly enabled,bulk_update
merges the provided JSON with the existing JSON field, following to the RFC 7386 - JSON Merge Patch standard. This feature supports both SQLite and PostgreSQL backend.Note:
attributes
andextra
are JSON fields of interest, and few additional JSON fields will be introduced. As a result, automatic detection of JSON fields is not implemented.bulk_update
logic for the SQLite DOS backend currently resides inPsqlDosBackend
. A dirty workaround has to be added inPsqlDosBackend
to address the differences between SQLite and PostgreSQL. This is also stated in a comment block in the code.