The main thing I was worried about is that the changes would be applied in replication in the order that I made them (assuming I made the changes from one node). In our case, we associate IP address documents that contain DNS host information. We'd like to make sure that a dns hostname is only ever associated with the correct IP address, so that when I move the dns hostname from from one IP address document to another, I can be sure that if it shows up in the new document, it is NOT in the old one.
I know that perhaps a more preferred way of making sure non-duplicity would be to make dns documents instead, but that constraint is not universal. Sometimes I do want multiple IP addresses for a domain. Just sometimes I don't, and I want to make sure that change can be counted on happening the way that I've done it. On May 18, 2011, at 6:28 PM, Sean Copenhaver wrote: > I'm curious why are you worried about multiple revisions of a document? > > > > On May 18, 2011, at 7:20 PM, Paul Davis <[email protected]> wrote: > >> On Wed, May 18, 2011 at 7:08 PM, Ryan 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 >> >> The updates are applied in the order of the update sequence. You can >> view that sequence using the changes feed. Your proposed scenario is >> listed under "assuming those are the only two edits applied to those >> two docs in any database that ever replicates with your network of >> dbs, then yes".
