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:48:09 GMT

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 <> wrote:
>> 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