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 <B.Candler@pobox.com> 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