Modifications draft

Many store implementations provide a modify operation to put objects, add box entries, and remove box entries in a single request. This increases efficiency over high-latency links, and allows to carry out a data transaction on forward-moving data with a single request.

Operation

The modify operation takes a set of objects, a set of additions, and a set of removals, and executes them as a single operation:

An object entry consists of an object and its hash. An addition or removal operation consist of an account hash, a box label, and a hash.

The operation proceeds in three steps:

1. All objects are stored. If this fails, processing stops here, and the operation fails.
2. All additions are processed. If any addition fails, processing stops, and the operation fails. Additions may be executed in any order, or concurrently. Hence, if the operation fails, some additions may have succeeded.
3. All removals are processed, and errors are ignored. The operation is considered successful even if some or all removals fail.

Note that additions are processed only after objects were store, and removals are processed only after successful completion of all additions. This ensures that the store keeps a consistent state at all times.

Concurrency

Multiple modification or box listing requests may be processed concurrently. A list request may see the result of a partially executed modification request.

An added entry may not exist any more by the time the modify operation returns, as a concurrent removal request may have removed it.

Failing removals

A failing (or deferred) removal does not break consistency within a forward-moving data model. Therefore, errors related to removals are ignored.

However, if an entry is repeatedly submitted for removal, stores must eventually remove it.