Hi, all. I'm working on updating the Wiki to describe the new behavior of bulk updates.
I read the very (very) long thread about Damien's change to the transactional semantics around _bulk_docs, and I understand the situation pretty well (I think). But there's one part of the discussion that I wanted to make sure I had correct. My understanding is that one motivation for bulk update may be because you have referential dependencies between docs. If there are no conflicts, then you can be assured those references will be consistent on the database where you do the bulk update (with all-or-nothing), *but* they may not immediately be consistent on replicas. This is because a bulk update is not replicated all-or-nothing, but instead each document is replicated independently, in an unspecified order. So you will have a temporary state of affairs where the references between documents may be inconsistent, but eventually they do become consistent (for that particular bulk update). *But* if you *do* have conflicts in a bulk update, then it is quite possible that the choice of winners for the conflict will cause a referential inconsistency between documents. In this case, the inconsistency will *not* automatically become eventually consistent, but will require intervention by the application to resolve the documents to a consistent state. This can happen even when you are not using replication at all, but you have two simultaneous sessions update the same document. In the previous implementation, bulk_update rolled back if there were any "local" conflicts, so you were guaranteed of referential consistency between docs on the database instance where you applied the bulk update. However, you could still end up in a pickle if replication caused a conflict -- now you are back in the same place with referential inconsistency that has to be manually resolved. Do I have that right? I am uncomfortable about asking the next question, as I feel I am opening up a can of worms, but I am missing what problem was solved by allowing all-or-nothing to succeed on conflicts. It seems like in both models you have eventual consistency and interim states where documents are inconsistent, but at least with the old approach you were guaranteed consistency on the database instance where you did the bulk update. That seems like it could be pretty handy, particularly for deployments where you are not doing replication. My apologies if this was already answered in that very long thread, but perhaps someone can summarize for me... Thanks, David -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
