Repository navigation
Strict add operator #3
Description
( from John Huffaker)
In concurrent modification scenarios test plus add/replace work great to avoid one user silently overwriting another user's modifications. The problem occurs when two users try to both add the same key (with different values) concurrently.
The test operator can't check for non-existence and their is no strict add operator that fails if the key already exists. I could resort to some other form of course grained locking but I really like the fine grained optimistic locking allowed by the current spec. Is a strict add operator on the horizon or should we add a non-standard operator to handle our use-case?
Activity
huggsboson commentedon May 8, 2014
s/their/there. [ashamed face]
briancavalier commentedon May 8, 2014
I'm generally +1 on this as well. While the "add-acts-like-replace-for-existing-keys" behavior can be convenient in some cases, it also means that
addhas at least 2 possible inverses:removeandreplace(ie did it add or did it replace??). In fact, one could say that it has 3, sinceadditself, when used likereplacecould be an inverse ofadd!It makes #2 much easier if
addhas only 1 inverse.espadrine commentedon Aug 23, 2016
This feels similar to the upsert problem, reversed. Most database systems offer insert and update, but no upsert (aka "update if it exists, insert if not"). JSON Patch has upsert (add) and update (replace), but no insert — which could therefore be the operation name.
As a side-note, this is addressed by #14 as well.
streamich commentedon Sep 3, 2020
This can be achieved using JSON Predicate
undefinedoperation. For example:[ {"op": "undefined", "path": "/foo"}, {"op": "add", "path": "/foo", "value": "bar"} ]I've implemented it in
json-joy.