Oh, sorry for two answers, I noticed Dan already answered to some concerns
On Mon, Sep 8, 2014 at 12:33 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch <rhauch(a)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
Any given REST call that leads to updating more than one endpoint is not
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?