On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <jch...@gmail.com> 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. -- Jason Smith Couchio Hosting
