couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: Proposal for changes in view server/protocol
Date Sun, 01 Aug 2010 18:38:18 GMT

On Aug 1, 2010, at 11:34 AM, Jason Smith wrote:

> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <> wrote:
>> I'm totally +1 on getting rid of these rough edges. I seriously doubt I'll
>> have time to do anything but cheerlead, so if this is gonna happen, someone
>> is gonna have to take up the charge.
> Do you mind a little discussion about how that might work?
> It seems to me there is no avoiding round trips between the _update function
> and couchdb.
> Is it allowed for the update function to query couchdb about whether id X is
> available?
> Is it allowed (or preferred) for the update function to have an additional
> flag similar to rereduce, indicating it is being called again due to a bad
> _id? What about two bad _ids in a row? Is the function called indefinitely
> with a growing list of previously-bad _ids until it returns an already-seen
> bad _id, in which case you get a 409? None of this strikes me as clean.
> Another thing to consider is perhaps the _update function can just specify
> what to render in the case of conflict and let the client handle it. I think
> that would be sufficient to at least allow a basic HTML form workflow again.

I like this the best. It could return:

"success": "<p>it worked</p>",
"conflict" : "<p>sorry, out of date rev made an update conflict, please reload and retry</p>",
"error" : "<p>yikes, I don't know what went wrong</p>"

and if any are missing you get the CouchDB json response instead

> -- 
> Jason Smith
> Couchio Hosting

View raw message