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 <[email protected]> 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
