You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jason Smith <jh...@couch.io> on 2010/08/01 20:34:02 UTC
Re: Proposal for changes in view server/protocol
On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <jc...@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
Re: Proposal for changes in view server/protocol
Posted by Jason Smith <jh...@couch.io>.
On Mon, Aug 2, 2010 at 01:48, J Chris Anderson <jc...@apache.org> wrote:
> 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.
>
The recent _config change for unauthorized queries should probably inform
this discussion.
--
Jason Smith
Couchio Hosting
Re: Proposal for changes in view server/protocol
Posted by Jason Smith <jh...@couch.io>.
I coded up an instructive example. This is not at this time a candidate for
merging, just something to consider.
Update functions receive a third parameter called "failures". The update
function is re-executed if a save was not possible, with the `failures`
object accumulating a map of failed document _ids to the reason for the
failure. For example {"some_id": {"validation": {"forbidden", "I am
_design/mean and I hate all documents!"}}}
http://github.com/jhs/couchdb/commit/9147281fb664b78b9fe639da91d96f819b92479d
This is an instructive update funciton:
http://friendpaste.com/4xckLZzYr4XSXhbAAGIBhj
I would like to hear critiques of this approach, if possible addressing its
pros:
* It exists
* Backward-compatible with existing update function code
* No change to the view server protocol
* Update functions know why the failure occurs, including the validation
error thrown by `validate_doc_update`
* For successful saves, the function runs once
* In the typical case, for unsuccessful saves, the function runs twice:
once to fail, and the second time to react to the failure. (In practice
updaters are not likely to continue guessing at alternative _ids because if
any old _id would work, then they would choose `req.uuid`.)
Of course I would like to alternatives to improve on this proposal's cons:
* A little bit complex
* A function called `update` is now doing document save error handling
* Bears similarity to the old _list functions that nobody liked
* Conceptually, it is over-engineering for a function to execute
recursively simply because it wants to know if a document can be saved.
(Although I took the idea from the Erlang pattern of looping over and over,
while accumulating state.)
In closing, I will reiterate the first point: it exists :)
--
Jason Smith
Couchio Hosting
Re: Proposal for changes in view server/protocol
Posted by Mikeal Rogers <mi...@gmail.com>.
No, that's not enough.
You want to handle the error, you want the ability to return an HTTP forward
to a show function if the update is successful OR to a newly generated
"success" page.
These are pretty standard HTTP form semantics and they can't be handled with
a single function in a nice way.
Also, your proposal doesn't have a good way to propagate the update error
back to the error page which is essential.
This is the kind of thing most modern web framework provide a simple high
level abstraction for. We don't need the high level thing but we do need a
good API that binds a particular "update" to all the HTTP and related
database calls it needs to make. Without that nobody can even build the high
level thing.
-Mikeal
On Sun, Aug 1, 2010 at 11:48 AM, J Chris Anderson <jc...@apache.org> wrote:
>
> 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 <jc...@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 <jc...@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
> >>
> >>
>
>
Re: Proposal for changes in view server/protocol
Posted by J Chris Anderson <jc...@apache.org>.
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 <jc...@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 <jc...@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
>>
>>
Re: Proposal for changes in view server/protocol
Posted by Mikeal Rogers <mi...@gmail.com>.
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 <jc...@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 <jc...@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
>
>
Re: Proposal for changes in view server/protocol
Posted by J Chris Anderson <jc...@apache.org>.
On Aug 1, 2010, at 11:34 AM, Jason Smith wrote:
> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <jc...@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