Strict add operator

[mnot]

( 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?

[huggsboson]

s/their/there. [ashamed face]

[briancavalier]

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 add has at least 2 possible inverses: remove and replace (ie did it add or did it replace??). In fact, one could say that it has 3, since add itself, when used like replace could be an inverse of add!

It makes #2 much easier if add has only 1 inverse.

[espadrine]

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]

This can be achieved using JSON Predicate undefined operation. For example:

[
  {"op": "undefined", "path": "/foo"},
  {"op": "add", "path": "/foo", "value": "bar"}
]

I've implemented it in json-joy.