On Fri, May 22, 2009 at 2:22 PM, Brian Candler <[email protected]> wrote: > On Fri, May 22, 2009 at 01:46:54PM -0700, Chris Anderson wrote: >> > Exactly. It'd be a "trivial" change to the batch=ok feature to add >> > wait=true so that the client hangs open on the connection and receives >> > a 201 Created when the batch is committed. It'd actually be sort of a >> > challenging patch, but I can perhaps add it before 1.0. >> > >> > I've added it to Jira here: >> > https://issues.apache.org/jira/browse/COUCHDB-356 >> >> Forgot to mention that you can almost get this now by using batch=ok >> and then when the client wants to be sure that the batch is committed, >> send a POST to /db/_ensure_full_commit >> >> You'll have a little more http overhead this way but the semantics are >> mostly the same. > > Hmm. So what are the semantics? Are you saying that _ensure_full_commit > doesn't actually cause a commit, but waits until the next commit takes > place? (What if the commit had already taken place?)
batch=ok with wait=true will return 201 Created with the same guarantees as a normal PUT, but using a RAM buffer to smooth index updates. You can approximate the behavior by using batch=ok and sending _ensure_full_commit periodically. If CouchDB has crashed you can act like the docs saved since the last _ensure_full_commit are potentially lost. For bonus points, track the db start time to avoid missing quick restarts. Chris > > Also: what exactly is the difference with or without batch=ok? Does batch=ok > mean that the doc sits in CouchDB's RAM buffer, and without it, it gets > written out to the kernel's VFS buffer (also in RAM)? In that case, I can't > really see why they would be any different from the client's point of view. > But I've probably misunderstood. > > Regards, > > Brian. > -- Chris Anderson http://jchrisa.net http://couch.io
