incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@apache.org>
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 <jchris@apache.org> wrote:
> 
>> 
>> On Aug 1, 2010, at 11:34 AM, Jason Smith wrote:
>> 
>>> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <jchris@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.
>>> 
>> 
>> 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
>> 
>> 


Mime
View raw message