couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Replication Order
Date Fri, 20 May 2011 08:00:10 GMT
Hi Ryan,

It's basically in _changes order but the replicator has some
parallelism, so you shouldn't depend on strict replay ordering at your
application level (it will not be honored). Assume 'no ordering' when
designing your application.

The job of replication is to ensure that the current revision of all
documents on the source are present at the target, this includes all
the conflicts.

The technique of deleting a document and recreating with a new id is
guaranteed to cause the problem you are seeking to avoid. When you
replicate, the target server will be in a state, albeit usually
briefly, where neither doc exists, and a state where both exists,
depending on luck.

The correct method is to update the document (same id) to its new
state. A document update is atomic, including when it's replicated.

B.

On 18 May 2011 23:40, Ryan D Hiebert <rhiebert@puc.edu> wrote:
> When replication is being done, in what order will the changes be applied?  In the order
that they happened, or in the order of the _id they refer to, or some other ordering, or is
there no ordering that can be expected.  For instance, if I move a document, I would like
to make sure that I never have two versions of the document.  To this end, I first delete
the document, and then create it again with the new _id.  In a replicated database, can I
be sure that the document will be first deleted, and then created on the replicated database?
>
> Thanks,
>
> Ryan

Mime
View raw message