Thanks for fixing this, Brian. I'm not sure I'm totally happy with these semantics. Unless I am missing something (more than possible as I'm still learning CouchDB), for a bulk update with N documents, you would have to do 1 round-trip for the update and N round-trips to check for conflicts (or, if not using all-or-nothing, N round-trips to check and see if the update was successful or not).
Isn't there any way for the response to a bulk update to tell you which documents have conflicts or failures? If what I'm saying above is correct, I would probably just do regular PUTs and skip bulk update functionality altogether. David On Tue, Mar 24, 2009 at 7:08 AM, Brian Candler <[email protected]> wrote: > On Tue, Mar 24, 2009 at 08:27:09AM +0000, Chris Anderson wrote: > > Don't be afraid to edit it! > > I just didn't want to stomp on it while someone else was working, and > create > more edit conflicts :-) > > I have fixed it now, except that I still don't know whether the > all_or_nothing commit boundary is preserved during replication. > > Regards, > > Brian. > -- 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
