On Wed, Jan 28, 2009 at 1:21 AM, Brian Candler <[email protected]> wrote:
> On Wed, Jan 28, 2009 at 09:05:20AM +0000, Brian Candler wrote:
>> Again looking at source, I see two very different paths in couch_db.erl
>> depending on the presence of that magic header:
>>
>> update_docs(Db, Docs, Options, false) -> ...
>> update_docs(Db, Docs, Options, true) -> ...
>
> Sorry, that was a mistake. It's the Options parameter which contains [] or
> [full_commit]; the call from couch_http_db calls update_docs/3, and the
> fourth argument defaults to true.
>
> I'm not sure what the false version of this function does - something to do
> with not allocating new revs? - but it's not relevant in this case.
>
It's cool that you are digging in like this. The false option is used
by the replication API.
> If there are any uuid conflicts then the whole
> batch will fail, and I'll have to patch it up and resubmit the whole lot.
The transactional nature of bulk_docs may not continue to hold, or
there may be an option to continue inserting even if some docs fail,
and then return the status of each doc as a list.
re: {minor_version,1}
I remember reading about that feature. I'm not sure what the arguments
are on either side. So far we haven't seen any reason to worry about
our number handling in Erlang. Maybe someone out there has a good
argument for switching to it?
> if multiple clients are PUTting individual documents, does a
> write-sync-write-sync take place for each one?
Writes to disk are synchronous (eg one writer per file).
There is an option to delay and batch writes. There has been recent
changes in the source around this area. I think the default puts
performance ahead of absolute consistency, but for critical apps you
should use X-Couch-Full-Commit: true
--
Chris Anderson
http://jchris.mfdz.com
