On Aug 1, 2010, at 11:46 AM, Mikeal Rogers wrote: > I've been thinking about this a lot lately and I'm starting to think > that continuing to build on the update function isn't the best idea. > > The update function just wasn't designed with this in mind. >
I don't get it, this seems a perfectly sensible enhancement to the current API. All that is missing is the ability to not spew garbage to the user on failure conditions. > Any way I can think of to add support for this use case to the update > function ends with a API I wouldn't actually want to use. Meanwhile, for > simpler cases the update function is still one of my favorite APIs and I > don't like the idea of complicating it. > > Maybe it's best here to design a new API called "form" or something similar. > We could build in the standard redirect system and failure cases and make > the API really nice to use and just leave update alone. > > Thoughts? > > -Mikeal > > On Sun, Aug 1, 2010 at 11:38 AM, J Chris Anderson <[email protected]> wrote: > >> >> On Aug 1, 2010, at 11:34 AM, Jason Smith wrote: >> >>> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <[email protected]> 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 >> >>
