couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: Proposal for changes in view server/protocol
Date Sun, 01 Aug 2010 18:46:17 GMT
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.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message