Oh, sorry for two answers, I noticed Dan already answered to some concerns already. :-)

On Mon, Sep 8, 2014 at 12:33 PM, Lukáš Fryč <lukas.fryc@gmail.com> wrote:

On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch <rhauch@redhat.com> wrote:

It’s also likely that for batch operations to work well for many different kinds of applications, the server may support multiple policies that specify for a given batch operation the atomicity, consistency, and isolation guarantees. One policy might ensure that the entire batch either completely succeeds only when there are no revision conflicts, otherwise it completely fails. Another policy might be eventually-consistent in the sense that the changes in every batch operations will eventually be applied, though this may require the server to have application-specific conflict resolution logic. And there are policies that are somewhere in-between. For example, imagine a server that supports “public” collections whose entities can be read/updated by any user, and “private” collections that expose only the entities that are readable and editable by that user. The likelihood of a concurrent update conflict on a private entity is quite small, since it’s possible only when different changes made on different devices are submitted at exactly the same time. On the other hand, the likelihood of a concurrent update conflict on a public entity is much higher. The server may allow updates to both public and private entities within a single batch operation, and a save policy that might update all private entities atomically (they all succeed or they all fail) while updates to *each* public entity is atomic (some might succeed while others might fail).

I don't believe LiveOak ensure ACID guarantees (at least not on batch update level; correct me if I'm wrong), and I don't think we should start with that.
Any given REST call that leads to updating more than one endpoint is not atomic anymore.

I would rather say that whole Data Sync is eventually consistent solution (at least in its first versions).

Sure, app/user will know that there is a conflict on one of the updated entities (and we may provide an API to make the resolution easier), but it will be up to him to resolve it.

Or am I wrong?