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/06/12 13:24:32 UTC
Auto-UUID generation in _update [PATCH]
I enjoy using _show and _update functions to mimic the HTTP doc API,
adding conveniences such as auto-timestamping, etc.
One thing _update cannot duplicate vs. the normal API is automatic UUID
generation when _id is unspecified.
The only solution is to generate a UUID in the update function; but this
sacrifices reference locality using the (default) sequential internal
UUID algorithm.
Is this just something we have to endure, or can couchdb be made to fill
it in? In principle, I feel like _update is a convenience around the
doc API. Auto-ID should be possible.
Attached is a patch as food for thought; however it has a bug: the query
server already computed the response (with arbitrary content-type and
response body). It seems too late for the couch server to go inserting
fields in the doc. But of course, the doc is invalid in the first place
if _id is undefined.
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Jason Smith <jh...@couch.io>.
Yes, and of course _update functions can receive arbitrary input: CSV, XML,
whatever.
I simply like the pattern where they mimic the JSON API but add extra
seasoning.
It's a pickle.
On Sat, Jun 12, 2010 at 22:18, Paul Bonser <mi...@gmail.com> wrote:
> I just realized that there's nothing keeping the update handler from
> generating a new document no matter if an existing document was passed
> in or not. So perhaps the uuid should simply always be added to the
> req passed into update handlers, so they always have one on hand if
> they want to create a new document?
>
> It could be handy if you want to generate a new document based on an
> existing document or related to an existing document, but want to
> leave the existing document intact.
>
> On Sat, Jun 12, 2010 at 10:16 AM, Paul Bonser <mi...@gmail.com> wrote:
> > How about instead of the update function passing back a doc with no
> > ID, if no docid is specified, then a uuid is generated and passed to
> > the update handler in the req? That way it can pass the auto-generated
> > ID back to the client as well.
> >
> > See the attached patch.
> >
> > At first I was going to just suggest passing a new uuid in the DocID
> > attribute to json_req_obj, but the problem with that would be the
> > inability to distinguish between a non-existing user-supplied ID and
> > an auto-generated ID, so I instead added it to a new "uuid" attribute
> > on the request parameter to the update function.
> >
> > On Sat, Jun 12, 2010 at 6:24 AM, Jason Smith <jh...@couch.io> wrote:
> >> I enjoy using _show and _update functions to mimic the HTTP doc API,
> >> adding conveniences such as auto-timestamping, etc.
> >>
> >> One thing _update cannot duplicate vs. the normal API is automatic UUID
> >> generation when _id is unspecified
> >>
> >> The only solution is to generate a UUID in the update function; but this
> >> sacrifices reference locality using the (default) sequential internal
> >> UUID algorithm.
> >>
> >> Is this just something we have to endure, or can couchdb be made to fill
> >> it in? In principle, I feel like _update is a convenience around the
> >> doc API. Auto-ID should be possible.
> >>
> >> Attached is a patch as food for thought; however it has a bug: the query
> >> server already computed the response (with arbitrary content-type and
> >> response body). It seems too late for the couch server to go inserting
> >> fields in the doc. But of course, the doc is invalid in the first place
> >> if _id is undefined.
> >>
> >> --
> >> Jason Smith
> >> Couchio Hosting
> >>
> >
> >
> >
> > --
> > Paul Bonser
> > http://probablyprogramming.com
> >
>
>
>
> --
> Paul Bonser
> http://probablyprogramming.com
>
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Jan Lehnardt <ja...@apache.org>.
On 14 Jun 2010, at 07:10, Jason Smith wrote:
> On Mon, Jun 14, 2010 at 02:34, Paul Bonser <mi...@gmail.com> wrote:
> Looks like you forgot to attach the patch. I think your reasoning is
> sound. Whether or not it's an API change could be up for debate. Since
> the _update functionality isn't particularly well documented yet, I
> don't know if a lot of people are using it yet...
>
> My outbox shows I did; but the archive site throws an error for that message.
The mailing list strips large and non-plaintext attachments for you.
> Anyway, if this one fails it's okay because I will add a test case and submit it into JIRA. You know, due to all the enthusiasm I've seen for making CouchDB more symmetric! :)
JIRA is preferred (though not liked :) for patches :)
Cheers
Jan
--
Re: Auto-UUID generation in _update [PATCH]
Posted by Jason Smith <jh...@couch.io>.
On Mon, Jun 14, 2010 at 02:34, Paul Bonser <mi...@gmail.com> wrote:
> Looks like you forgot to attach the patch. I think your reasoning is
> sound. Whether or not it's an API change could be up for debate. Since
> the _update functionality isn't particularly well documented yet, I
> don't know if a lot of people are using it yet...
>
My outbox shows I did; but the archive site throws an error for that
message.
Anyway, if this one fails it's okay because I will add a test case and
submit it into JIRA. You know, due to all the enthusiasm I've seen for
making CouchDB more symmetric! :)
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Paul Bonser <mi...@gmail.com>.
Looks like you forgot to attach the patch. I think your reasoning is
sound. Whether or not it's an API change could be up for debate. Since
the _update functionality isn't particularly well documented yet, I
don't know if a lot of people are using it yet...
On Sat, Jun 12, 2010 at 12:41 PM, Jason Smith <jh...@couch.io> wrote:
> On Sat, Jun 12, 2010 at 23:18, Jason Smith <jh...@couch.io> wrote:
>>
>> On Sat, Jun 12, 2010 at 23:13, Paul Bonser <mi...@gmail.com> wrote:
>>>
>>> > Why not have these three cases:
>>> >
>>> > * Document update: doc is something, req.id == doc._id
>>> > * Document create, PUT to _update/some_id: doc is null, req.id is
>>> > "some_id"
>>> > * Document create, POST to _update, doc is null, req.is is a random
>>> > uuid
>>> >
>>> > The update function can decide whether or not to honor the "suggested"
>>> > doc
>>> > id but at least it is now capable of matching the JSON API.
>>>
>>> Ah yes, making it a bit closer to the way that a regular PUT vs. POST
>>> works. What if someone POSTs an ID as part of the _update request?
>>> Return an error telling them that they can only include a doc ID as
>>> part of a PUT?
>
> Wow, when you do it this way, it is just a 1-line patch (attached).
> The update function can now do
> if(doc && doc._id == req.id)
> // To be pedantic, I could confirm req.method == "PUT"
> log("I am an update by id");
> else if(doc === null && req.id) {
> if(req.method == "POST")
> log("I am a create, id was auto-generated");
> else if(req.method == "PUT")
> log("I am a create, id was supplied by client");
> }
> Thoughts? Does this count as an API change? Even if so, I feel like it fixes
> a bug.
>>
>> Well, my objective is that it is *possible* for _update to match the JSON
>> API.
>> Users can POST to _update/some_id with a JSON whose _id doesn't match. A
>> well-written update function would presumably return an error (or whatever
>> straight couch does).
>>>
>>> >
>>> > --
>>> > Jason Smith
>>> > Couchio Hosting
>>> >
>>>
>>>
>>>
>>> --
>>> Paul Bonser
>>> http://probablyprogramming.com
>>
>>
>>
>> --
>> Jason Smith
>> Couchio Hosting
>
>
>
> --
> Jason Smith
> Couchio Hosting
>
--
Paul Bonser
http://probablyprogramming.com
Re: Auto-UUID generation in _update [PATCH]
Posted by Jason Smith <jh...@couch.io>.
On Sat, Jun 12, 2010 at 23:18, Jason Smith <jh...@couch.io> wrote:
> On Sat, Jun 12, 2010 at 23:13, Paul Bonser <mi...@gmail.com> wrote:
>
>> > Why not have these three cases:
>> >
>> > * Document update: doc is something, req.id == doc._id
>> > * Document create, PUT to _update/some_id: doc is null, req.id is
>> "some_id"
>> > * Document create, POST to _update, doc is null, req.is is a random
>> uuid
>> >
>> > The update function can decide whether or not to honor the "suggested"
>> doc
>> > id but at least it is now capable of matching the JSON API.
>>
>> Ah yes, making it a bit closer to the way that a regular PUT vs. POST
>> works. What if someone POSTs an ID as part of the _update request?
>> Return an error telling them that they can only include a doc ID as
>> part of a PUT?
>>
>
Wow, when you do it this way, it is just a 1-line patch (attached).
The update function can now do
if(doc && doc._id == req.id)
// To be pedantic, I could confirm req.method == "PUT"
log("I am an update by id");
else if(doc === null && req.id) {
if(req.method == "POST")
log("I am a create, id was auto-generated");
else if(req.method == "PUT")
log("I am a create, id was supplied by client");
}
Thoughts? Does this count as an API change? Even if so, I feel like it fixes
a bug.
Well, my objective is that it is *possible* for _update to match the JSON
> API.
>
> Users can POST to _update/some_id with a JSON whose _id doesn't match. A
> well-written update function would presumably return an error (or whatever
> straight couch does).
>
>
>> >
>> > --
>> > Jason Smith
>> > Couchio Hosting
>> >
>>
>>
>>
>> --
>> Paul Bonser
>> http://probablyprogramming.com
>>
>
>
>
> --
> Jason Smith
> Couchio Hosting
>
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Jason Smith <jh...@couch.io>.
On Sat, Jun 12, 2010 at 23:13, Paul Bonser <mi...@gmail.com> wrote:
> > Why not have these three cases:
> >
> > * Document update: doc is something, req.id == doc._id
> > * Document create, PUT to _update/some_id: doc is null, req.id is
> "some_id"
> > * Document create, POST to _update, doc is null, req.is is a random
> uuid
> >
> > The update function can decide whether or not to honor the "suggested"
> doc
> > id but at least it is now capable of matching the JSON API.
>
> Ah yes, making it a bit closer to the way that a regular PUT vs. POST
> works. What if someone POSTs an ID as part of the _update request?
> Return an error telling them that they can only include a doc ID as
> part of a PUT?
>
Well, my objective is that it is *possible* for _update to match the JSON
API.
Users can POST to _update/some_id with a JSON whose _id doesn't match. A
well-written update function would presumably return an error (or whatever
straight couch does).
> >
> > --
> > Jason Smith
> > Couchio Hosting
> >
>
>
>
> --
> Paul Bonser
> http://probablyprogramming.com
>
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Paul Bonser <mi...@gmail.com>.
On Sat, Jun 12, 2010 at 10:48 AM, Jason Smith <jh...@couch.io> wrote:
> On Sat, Jun 12, 2010 at 22:18, Paul Bonser <mi...@gmail.com> wrote:
>
>> I just realized that there's nothing keeping the update handler from
>> generating a new document no matter if an existing document was passed
>> in or not.
>
>
> My feeling about that is, hey, nothing stops you from writing a bad update
> function. You could return invalid JSON already. So I kind of like your
> auto-id on the way in idea. However that still doesn't answer the problem
> that _update in general does not process JSON, it processes text.
>
> I wonder, for
>
> function(doc, req) { ... }
>
> Why not have these three cases:
>
> * Document update: doc is something, req.id == doc._id
> * Document create, PUT to _update/some_id: doc is null, req.id is "some_id"
> * Document create, POST to _update, doc is null, req.is is a random uuid
>
> The update function can decide whether or not to honor the "suggested" doc
> id but at least it is now capable of matching the JSON API.
Ah yes, making it a bit closer to the way that a regular PUT vs. POST
works. What if someone POSTs an ID as part of the _update request?
Return an error telling them that they can only include a doc ID as
part of a PUT?
>
> --
> Jason Smith
> Couchio Hosting
>
--
Paul Bonser
http://probablyprogramming.com
Re: Auto-UUID generation in _update [PATCH]
Posted by Jason Smith <jh...@couch.io>.
On Sat, Jun 12, 2010 at 22:18, Paul Bonser <mi...@gmail.com> wrote:
> I just realized that there's nothing keeping the update handler from
> generating a new document no matter if an existing document was passed
> in or not.
My feeling about that is, hey, nothing stops you from writing a bad update
function. You could return invalid JSON already. So I kind of like your
auto-id on the way in idea. However that still doesn't answer the problem
that _update in general does not process JSON, it processes text.
I wonder, for
function(doc, req) { ... }
Why not have these three cases:
* Document update: doc is something, req.id == doc._id
* Document create, PUT to _update/some_id: doc is null, req.id is "some_id"
* Document create, POST to _update, doc is null, req.is is a random uuid
The update function can decide whether or not to honor the "suggested" doc
id but at least it is now capable of matching the JSON API.
--
Jason Smith
Couchio Hosting
Re: Auto-UUID generation in _update [PATCH]
Posted by Paul Bonser <mi...@gmail.com>.
I just realized that there's nothing keeping the update handler from
generating a new document no matter if an existing document was passed
in or not. So perhaps the uuid should simply always be added to the
req passed into update handlers, so they always have one on hand if
they want to create a new document?
It could be handy if you want to generate a new document based on an
existing document or related to an existing document, but want to
leave the existing document intact.
On Sat, Jun 12, 2010 at 10:16 AM, Paul Bonser <mi...@gmail.com> wrote:
> How about instead of the update function passing back a doc with no
> ID, if no docid is specified, then a uuid is generated and passed to
> the update handler in the req? That way it can pass the auto-generated
> ID back to the client as well.
>
> See the attached patch.
>
> At first I was going to just suggest passing a new uuid in the DocID
> attribute to json_req_obj, but the problem with that would be the
> inability to distinguish between a non-existing user-supplied ID and
> an auto-generated ID, so I instead added it to a new "uuid" attribute
> on the request parameter to the update function.
>
> On Sat, Jun 12, 2010 at 6:24 AM, Jason Smith <jh...@couch.io> wrote:
>> I enjoy using _show and _update functions to mimic the HTTP doc API,
>> adding conveniences such as auto-timestamping, etc.
>>
>> One thing _update cannot duplicate vs. the normal API is automatic UUID
>> generation when _id is unspecified
>>
>> The only solution is to generate a UUID in the update function; but this
>> sacrifices reference locality using the (default) sequential internal
>> UUID algorithm.
>>
>> Is this just something we have to endure, or can couchdb be made to fill
>> it in? In principle, I feel like _update is a convenience around the
>> doc API. Auto-ID should be possible.
>>
>> Attached is a patch as food for thought; however it has a bug: the query
>> server already computed the response (with arbitrary content-type and
>> response body). It seems too late for the couch server to go inserting
>> fields in the doc. But of course, the doc is invalid in the first place
>> if _id is undefined.
>>
>> --
>> Jason Smith
>> Couchio Hosting
>>
>
>
>
> --
> Paul Bonser
> http://probablyprogramming.com
>
--
Paul Bonser
http://probablyprogramming.com
Re: Auto-UUID generation in _update [PATCH]
Posted by Paul Bonser <mi...@gmail.com>.
How about instead of the update function passing back a doc with no
ID, if no docid is specified, then a uuid is generated and passed to
the update handler in the req? That way it can pass the auto-generated
ID back to the client as well.
See the attached patch.
At first I was going to just suggest passing a new uuid in the DocID
attribute to json_req_obj, but the problem with that would be the
inability to distinguish between a non-existing user-supplied ID and
an auto-generated ID, so I instead added it to a new "uuid" attribute
on the request parameter to the update function.
On Sat, Jun 12, 2010 at 6:24 AM, Jason Smith <jh...@couch.io> wrote:
> I enjoy using _show and _update functions to mimic the HTTP doc API,
> adding conveniences such as auto-timestamping, etc.
>
> One thing _update cannot duplicate vs. the normal API is automatic UUID
> generation when _id is unspecified
>
> The only solution is to generate a UUID in the update function; but this
> sacrifices reference locality using the (default) sequential internal
> UUID algorithm.
>
> Is this just something we have to endure, or can couchdb be made to fill
> it in? In principle, I feel like _update is a convenience around the
> doc API. Auto-ID should be possible.
>
> Attached is a patch as food for thought; however it has a bug: the query
> server already computed the response (with arbitrary content-type and
> response body). It seems too late for the couch server to go inserting
> fields in the doc. But of course, the doc is invalid in the first place
> if _id is undefined.
>
> --
> Jason Smith
> Couchio Hosting
>
--
Paul Bonser
http://probablyprogramming.com