You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Wout Mertens <wo...@gmail.com> on 2009/03/07 12:58:49 UTC
Please allow _prefix for auto-created _id
Hi devs,
Would it be possible to allow a _prefix parameter to be given when
creating a new document, which would be used for auto-generating an _id?
The reason I ask is that it's much harder to create a unique
descriptive id in an application than in a database.
In my application I have to create sessions in response to user
queries, and I can't generate a reasonably compact _id that's
guaranteed to be unique, at least not easily. If I could just give
CouchDB a _prefix instead of an _id, CouchDB could generate a
descriptive, compact, guaranteed unique _id for me instead.
E.g. I could create an _id as follows:
$ perl -e 'print "session_".crypt(join("",POSIX::uname).$
$.time,"42")."\n"'
session_42/xjrVvFTocQ
This seems ok at first but then it turns out that crypt only uses the
first 8 characters and this therefore always gives the same result. So
I have to use MD5, which means another module or at least imported
functions etc.
OR, I could simply add "_prefix":"session_" to the JSON and CouchDB
would return something like
session_91a92205f9e6df704fdcca5968a3cdfb for the _id. No extra code
from me, guaranteed unique, easy to remember.
Is this a convincing use case? :-D
I think that a prefix+unique suffix allows you to have a natural key
for lists of data. When you see that UUID referenced somewhere else,
just like a natural key, you immediately understand the function of
that reference.
Thanks,
Wout.
Re: Please allow _prefix for auto-created _id
Posted by Jan Lehnardt <ja...@apache.org>.
On 8 Mar 2009, at 18:05, Jens Alfke wrote:
>
> On Mar 7, 2009, at 3:38 PM, Jan Lehnardt wrote:
>
>> http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection&l=1
>> and more here:
>> http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection
>
> Haha. lmgtfy.com is really cute, and I've bookmarked it to use
> against annoying Help-Vampires on some other mailing lists I'm on,
> but in this case particular case it was pretty useless — it took me
> to an IBM page on "Implementing REST services with WebSphere" which
> looks like a basic intro to REST, with no mention of the POST
> problems being discussed here. Down around the fourth hit I found
> "Double POST and POE" which seems relevant; it would have saved me a
> couple of minutes had you just linked directly to that.
>
> Morals:
> • A search query is a really fragile thing to link to, given how
> frequently Google updates its index.
> • Don't point people to a "fuck-you" site like lmgtfy.com unless
> they're asking about something sufficiently obvious that the search
> query is a no-fail.
In hindsight my reply seems childish and not productive at all.
My apologies.
> —Jens
>
> PS: Anyone got a link to the specific CFNetwork bug? I used to work
> with the CFNetwork and Safari teams, and I don't remember this
> coming up.
http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html
I might be wrong in asserting that system-level HTTP is handled by
CFNetwork or some other framework or by Safari, but I think I remember
it being that way.
Cheers
Jan
--
Re: Please allow _prefix for auto-created _id
Posted by Jens Alfke <je...@mooseyard.com>.
On Mar 7, 2009, at 3:38 PM, Jan Lehnardt wrote:
> http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection&l=1
> and more here:
> http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection
Haha. lmgtfy.com is really cute, and I've bookmarked it to use against
annoying Help-Vampires on some other mailing lists I'm on, but in this
case particular case it was pretty useless — it took me to an IBM page
on "Implementing REST services with WebSphere" which looks like a
basic intro to REST, with no mention of the POST problems being
discussed here. Down around the fourth hit I found "Double POST and
POE" which seems relevant; it would have saved me a couple of minutes
had you just linked directly to that.
Morals:
• A search query is a really fragile thing to link to, given how
frequently Google updates its index.
• Don't point people to a "fuck-you" site like lmgtfy.com unless
they're asking about something sufficiently obvious that the search
query is a no-fail.
—Jens
PS: Anyone got a link to the specific CFNetwork bug? I used to work
with the CFNetwork and Safari teams, and I don't remember this coming
up.
Re: Please allow _prefix for auto-created _id
Posted by Jan Lehnardt <ja...@apache.org>.
On 8 Mar 2009, at 01:35, Antony Blakey wrote:
> On 08/03/2009, at 10:48 AM, Jan Lehnardt wrote:
>
>> http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
>> "safari sends post twice", seriously, this is tiring).
>
> Sorry, I tried a number of searches (e.g. "safari double post bug"),
> and couldn't find that.
>
> Is it possible to get some reciprocal benefit of the doubt rather
> than immediate hostility?
Fair enough, next round then :) (sorry)
Cheers
Jan
--
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 1:35 PM, Paul Davis wrote:
>> I don't see how this would solve the problem of e.g. double
>> invocations of a
>> replicate/compact/purge POST. I'm not sure what kind of delays
>> between
>> double POSTs one needs to deal with, but given that POSTs (and
>> maybe all
>> methods) do have this problem (regardless of whether the error is
>> in the
>> browser stack or middleware), this would seem to be a generic
>> solution that
>> cannot be solved in the client.
>>
>
> This is most likely because the issue at hand has nothing to do with
> replication, compaction, or purging. This issue can be solved in the
> client exactly as Chris described in the second email in this thread.
>
> The bottom line here is that you should not rely on CouchDB to
> automatically add a document id if you need to know that specific ID
> in the future. It is more than possible that the document is created
> without the client having knowledge of the new id due to any number of
> errors.
I'm not talking about documents - I accept those points and have
previously suggested that the API to create documents without an ID be
removed.
I'm proposing a generic solution to the problem of double POSTs for
non-document operations such as triggering a replication/compaction et
al.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
--Stephen F Roberts
Re: Please allow _prefix for auto-created _id
Posted by Paul Davis <pa...@gmail.com>.
On Sat, Mar 7, 2009 at 9:01 PM, Antony Blakey <an...@gmail.com> wrote:
>
> On 08/03/2009, at 11:43 AM, Chris Anderson wrote:
>
>> On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey <an...@gmail.com>
>> wrote:
>>>
>>> On 08/03/2009, at 11:14 AM, Damien Katz wrote:
>>>
>>>> The problem is if there is a network error, a client has no way to if a
>>>> POST commit was successful. The success or failure response can get
>>>> lost,
>>>> and the id of the document is completely unknown to the client.
>>>
>>> This is a different problem than the double post - would the same problem
>>> not occur if the client failed? e.g. if there's no way of finding the
>>> resultant document, then the failure modes seem symmetric.
>>>
>>
>> Client failure has to be expected. A POST is fire-and-forget. If you
>> use it right (as we strive to) you can even make it seem idempotent.
>> Tighter coupling between the client and server is the last thing we
>> need.
>
> Sure, but my point was that specific problem of creating a document and
> having the POST response fail to arrive (and hence be lost to the client),
> is equivalent to (and IMO much less likely than) the client failing. I'm not
> suggesting that Couch should deal with this case, and consequently I don't
> think it should deal with the POST response failing to arrive. At the moment
> I don't see how this has any relationship to the problem of duplicate posts.
>
The relationship is that duplicate posts only brought the problem to
light. Now that the issue is known we can tell people about it and how
to avoid it.
>>> Maybe a generic solution could
>>> be to allow a client supplied UUID in the request, which is retained in
>>> the
>>> server for some short time (in network terms) to make POSTs generically
>>> idempotent over some window?
>>>
>>
>> Setting up window agreement is not the sort of problem I think CouchDB
>> should strive to solve. It may be that CouchDB is well suited to it,
>> but I think the proper point of implementation is at the application
>> level. CouchDB aims to be a sort of lowest-common denominator. If you
>> implement is as a CouchApp that emits JSON and maintains server
>> closures in JavaScript, you'd pretty much have what you need, and it'd
>> be replicateable across raw CouchDB nodes.
>
> I don't see how this would solve the problem of e.g. double invocations of a
> replicate/compact/purge POST. I'm not sure what kind of delays between
> double POSTs one needs to deal with, but given that POSTs (and maybe all
> methods) do have this problem (regardless of whether the error is in the
> browser stack or middleware), this would seem to be a generic solution that
> cannot be solved in the client.
>
This is most likely because the issue at hand has nothing to do with
replication, compaction, or purging. This issue can be solved in the
client exactly as Chris described in the second email in this thread.
The bottom line here is that you should not rely on CouchDB to
automatically add a document id if you need to know that specific ID
in the future. It is more than possible that the document is created
without the client having knowledge of the new id due to any number of
errors.
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> Some defeats are instalments to victory.
> -- Jacob Riis
>
>
>
HTH,
Paul Davis
Re: Please allow _prefix for auto-created _id
Posted by Damien Katz <da...@apache.org>.
On Mar 8, 2009, at 12:32 AM, Antony Blakey wrote:
>
> On 08/03/2009, at 3:33 PM, Damien Katz wrote:
>
>> Replication and compaction are idempotent.
>
> Yes, although my experience has been that starting concurrent
> replications with the same parameters is a nightmare.
It shouldn't cause any problems, just extra work for the replicator.
If something else is happening, help us out and create a bug report.
> I guess Adam is going to have that fixed.
>
> One further area where this might be a problem is with your new bulk
> operation semantics i.e. a repeated POST will generate spurious self-
> conflicts, unlike single-doc updates - is that correct?
There is no difference between bulk update and single doc updates. It
all calls the same code in the database layer.
>
> Given the problem with POST is generic, and can be most effectively
> (only?) be solved with server cooperation, this still seems to me
> like a good idea. Furthermore, this would simplify the programing
> model for the user because they could assume that POSTs are never
> repeated rather than having to deal with the possibility. IMO
> servers should alway reify the concept of once-only operations given
> you can't rely on the network or the browser. Anyway, it seems I'm
> an outlier on this, and it's not like I have the time to do it.
>
>> Non-sequitur, you working on getting that file name patch finished?
>> It would be nice to have that for 0.9.0
>
> Not at the moment - I'm holding off until I see what I'm going to
> have to do to restore fail-on-conflict bulk operations for my
> private/deployed version - I'm not trying to convince anyone else.
> I'm accumulating my spare time for that in preference to filenames,
> because fail-on-conflict is in my face right now. Once I have that
> problem solved, if filenames is still outstanding then I'll
> resurrect it. Please don't read anything into that.
Ok, good luck with that. Whenever you get some spare time it would be
great if you could help out the project.
-Damien
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 3:33 PM, Damien Katz wrote:
> Replication and compaction are idempotent.
Yes, although my experience has been that starting concurrent
replications with the same parameters is a nightmare. I guess Adam is
going to have that fixed.
One further area where this might be a problem is with your new bulk
operation semantics i.e. a repeated POST will generate spurious self-
conflicts, unlike single-doc updates - is that correct?
Given the problem with POST is generic, and can be most effectively
(only?) be solved with server cooperation, this still seems to me like
a good idea. Furthermore, this would simplify the programing model for
the user because they could assume that POSTs are never repeated
rather than having to deal with the possibility. IMO servers should
alway reify the concept of once-only operations given you can't rely
on the network or the browser. Anyway, it seems I'm an outlier on
this, and it's not like I have the time to do it.
> Non-sequitur, you working on getting that file name patch finished?
> It would be nice to have that for 0.9.0
Not at the moment - I'm holding off until I see what I'm going to have
to do to restore fail-on-conflict bulk operations for my private/
deployed version - I'm not trying to convince anyone else. I'm
accumulating my spare time for that in preference to filenames,
because fail-on-conflict is in my face right now. Once I have that
problem solved, if filenames is still outstanding then I'll resurrect
it. Please don't read anything into that.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Success is not the key to happiness. Happiness is the key to success.
-- Albert Schweitzer
Re: Please allow _prefix for auto-created _id
Posted by Damien Katz <da...@apache.org>.
On Mar 7, 2009, at 11:35 PM, Antony Blakey wrote:
>
> On 08/03/2009, at 1:39 PM, Chris Anderson wrote:
>
>> On Sat, Mar 7, 2009 at 6:01 PM, Antony Blakey <antony.blakey@gmail.com
>> > wrote:
>>
>>> I don't see how this would solve the problem of e.g. double
>>> invocations of a
>>> replicate/compact/purge POST. I'm not sure what kind of delays
>>> between
>>> double POSTs one needs to deal with, but given that POSTs (and
>>> maybe all
>>> methods) do have this problem (regardless of whether the error is
>>> in the
>>> browser stack or middleware), this would seem to be a generic
>>> solution that
>>> cannot be solved in the client.
>>>
>>
>> The ingredients for solving it are deterministic revs and
>> non-colliding client-specified docids.
>
> I must be missing something - how does this stop a double POST to /
> replicate et al caused by a browser stack or middleware error?
Replication and compaction are idempotent.
Non-sequitur, you working on getting that file name patch finished? It
would be nice to have that for 0.9.0
-Damien
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 1:39 PM, Chris Anderson wrote:
> On Sat, Mar 7, 2009 at 6:01 PM, Antony Blakey
> <an...@gmail.com> wrote:
>
>> I don't see how this would solve the problem of e.g. double
>> invocations of a
>> replicate/compact/purge POST. I'm not sure what kind of delays
>> between
>> double POSTs one needs to deal with, but given that POSTs (and
>> maybe all
>> methods) do have this problem (regardless of whether the error is
>> in the
>> browser stack or middleware), this would seem to be a generic
>> solution that
>> cannot be solved in the client.
>>
>
> The ingredients for solving it are deterministic revs and
> non-colliding client-specified docids.
I must be missing something - how does this stop a double POST to /
replicate et al caused by a browser stack or middleware error?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B
will do it very easily and for a very reasonable price, but I don't
want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and
$CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on
how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape,
an iPod, and hours and hours of my precious time.
-- Slashdot response to an enquiry
Re: Please allow _prefix for auto-created _id
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Mar 7, 2009 at 6:01 PM, Antony Blakey <an...@gmail.com> wrote:
> I don't see how this would solve the problem of e.g. double invocations of a
> replicate/compact/purge POST. I'm not sure what kind of delays between
> double POSTs one needs to deal with, but given that POSTs (and maybe all
> methods) do have this problem (regardless of whether the error is in the
> browser stack or middleware), this would seem to be a generic solution that
> cannot be solved in the client.
>
The ingredients for solving it are deterministic revs and
non-colliding client-specified docids.
--
Chris Anderson
http://jchris.mfdz.com
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 11:43 AM, Chris Anderson wrote:
> On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey
> <an...@gmail.com> wrote:
>>
>> On 08/03/2009, at 11:14 AM, Damien Katz wrote:
>>
>>> The problem is if there is a network error, a client has no way to
>>> if a
>>> POST commit was successful. The success or failure response can
>>> get lost,
>>> and the id of the document is completely unknown to the client.
>>
>> This is a different problem than the double post - would the same
>> problem
>> not occur if the client failed? e.g. if there's no way of finding the
>> resultant document, then the failure modes seem symmetric.
>>
>
> Client failure has to be expected. A POST is fire-and-forget. If you
> use it right (as we strive to) you can even make it seem idempotent.
> Tighter coupling between the client and server is the last thing we
> need.
Sure, but my point was that specific problem of creating a document
and having the POST response fail to arrive (and hence be lost to the
client), is equivalent to (and IMO much less likely than) the client
failing. I'm not suggesting that Couch should deal with this case, and
consequently I don't think it should deal with the POST response
failing to arrive. At the moment I don't see how this has any
relationship to the problem of duplicate posts.
>> Maybe a generic solution could
>> be to allow a client supplied UUID in the request, which is
>> retained in the
>> server for some short time (in network terms) to make POSTs
>> generically
>> idempotent over some window?
>>
>
> Setting up window agreement is not the sort of problem I think CouchDB
> should strive to solve. It may be that CouchDB is well suited to it,
> but I think the proper point of implementation is at the application
> level. CouchDB aims to be a sort of lowest-common denominator. If you
> implement is as a CouchApp that emits JSON and maintains server
> closures in JavaScript, you'd pretty much have what you need, and it'd
> be replicateable across raw CouchDB nodes.
I don't see how this would solve the problem of e.g. double
invocations of a replicate/compact/purge POST. I'm not sure what kind
of delays between double POSTs one needs to deal with, but given that
POSTs (and maybe all methods) do have this problem (regardless of
whether the error is in the browser stack or middleware), this would
seem to be a generic solution that cannot be solved in the client.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
Re: Please allow _prefix for auto-created _id
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey <an...@gmail.com> wrote:
>
> On 08/03/2009, at 11:14 AM, Damien Katz wrote:
>
>> The problem is if there is a network error, a client has no way to if a
>> POST commit was successful. The success or failure response can get lost,
>> and the id of the document is completely unknown to the client.
>
> This is a different problem than the double post - would the same problem
> not occur if the client failed? e.g. if there's no way of finding the
> resultant document, then the failure modes seem symmetric.
>
Client failure has to be expected. A POST is fire-and-forget. If you
use it right (as we strive to) you can even make it seem idempotent.
Tighter coupling between the client and server is the last thing we
need.
> Maybe a generic solution could
> be to allow a client supplied UUID in the request, which is retained in the
> server for some short time (in network terms) to make POSTs generically
> idempotent over some window?
>
Setting up window agreement is not the sort of problem I think CouchDB
should strive to solve. It may be that CouchDB is well suited to it,
but I think the proper point of implementation is at the application
level. CouchDB aims to be a sort of lowest-common denominator. If you
implement is as a CouchApp that emits JSON and maintains server
closures in JavaScript, you'd pretty much have what you need, and it'd
be replicateable across raw CouchDB nodes.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 11:14 AM, Damien Katz wrote:
> The problem is if there is a network error, a client has no way to
> if a POST commit was successful. The success or failure response can
> get lost, and the id of the document is completely unknown to the
> client.
This is a different problem than the double post - would the same
problem not occur if the client failed? e.g. if there's no way of
finding the resultant document, then the failure modes seem symmetric.
> But if the client knows the doc id beforehand, then it can later
> check the db (or reattempt the update) to see if the update was
> successful or lost. And wIth deterministic rev ids, the client could
> just do the update again and get a success response despite the
> update maybe already having being committed.
This suggests that the POST without an id should be removed from the
API. Most of the other APIs have revs, which protect the model from
this bug, resulting in mere user confusion. And this prompts a thought
about a similar problem with replicate/compact/purge et al. Maybe a
generic solution could be to allow a client supplied UUID in the
request, which is retained in the server for some short time (in
network terms) to make POSTs generically idempotent over some window?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There is nothing more difficult to plan, more doubtful of success, nor
more dangerous to manage than the creation of a new order of things...
Whenever his enemies have the ability to attack the innovator, they do
so with the passion of partisans, while the others defend him
sluggishly, So that the innovator and his party alike are vulnerable.
-- Niccolo Machiavelli, 1513, The Prince.
Re: Please allow _prefix for auto-created _id
Posted by Damien Katz <da...@apache.org>.
On Mar 7, 2009, at 7:35 PM, Antony Blakey wrote:
>
> On 08/03/2009, at 10:48 AM, Jan Lehnardt wrote:
>
>> http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
>> "safari sends post twice", seriously, this is tiring).
>
> Sorry, I tried a number of searches (e.g. "safari double post bug"),
> and couldn't find that.
>
> Is it possible to get some reciprocal benefit of the doubt rather
> than immediate hostility?
>
>>> Those lmgtfy links seem to be about the double post being
>>> triggered by the browser client, as opposed to e.g. a ruby client.
>>> I knew about that problem, but I've not seen a problem report due
>>> to *middleware* e.g. proxy/cache ignoring the non-idempotency of
>>> POST.
>>
>> The point is that CouchDB can't know if requests come from a broken
>> or compliant middleware system with new ones coming up all the time.
>
> But we're only talking about this problem in the context of XHR
> right? And so the advice to not use POST without a UUID is specific
> to XHR apps, rather than all use cases?
The problem is if there is a network error, a client has no way to if
a POST commit was successful. The success or failure response can get
lost, and the id of the document is completely unknown to the client.
But if the client knows the doc id beforehand, then it can later check
the db (or reattempt the update) to see if the update was successful
or lost. And wIth deterministic rev ids, the client could just do the
update again and get a success response despite the update maybe
already having being committed.
-Damien
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 10:48 AM, Jan Lehnardt wrote:
> http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
> "safari sends post twice", seriously, this is tiring).
Sorry, I tried a number of searches (e.g. "safari double post bug"),
and couldn't find that.
Is it possible to get some reciprocal benefit of the doubt rather than
immediate hostility?
>> Those lmgtfy links seem to be about the double post being triggered
>> by the browser client, as opposed to e.g. a ruby client. I knew
>> about that problem, but I've not seen a problem report due to
>> *middleware* e.g. proxy/cache ignoring the non-idempotency of POST.
>
> The point is that CouchDB can't know if requests come from a broken
> or compliant middleware system with new ones coming up all the time.
But we're only talking about this problem in the context of XHR right?
And so the advice to not use POST without a UUID is specific to XHR
apps, rather than all use cases?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
75% of statistics are made up on the spot.
Re: Please allow _prefix for auto-created _id
Posted by Jan Lehnardt <ja...@apache.org>.
On 8 Mar 2009, at 01:04, Antony Blakey wrote:
>
> On 08/03/2009, at 10:08 AM, Jan Lehnardt wrote:
>
>>
>> On 8 Mar 2009, at 00:22, Antony Blakey wrote:
>>
>>>
>>> On 08/03/2009, at 4:41 AM, Chris Anderson wrote:
>>>
>>>> Currently it's recommended not to POST new documents without ids to
>>>> CouchDB. Due to HTTP protocol issues this can result in duplicate
>>>> document creation.
>>>
>>> I've never really understood this. Wouldn't it mean that all POST
>>> operations in CouchDB need to be made idempotent by the server
>>> because they might be erroneously repeated by middleware?
>>
>> Correct, a bug in Safari / CFNetwok brought this up.
>
> I can't find a reference to a Safari/CFNetwork double post problem.
> Do you have one? Will it become obsolete?
http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
"safari sends post twice", seriously, this is tiring).
> One implication of this is that a create or update might return a
> 412, even though it has succeeded, because the client is seeing the
> response from the second, repeated POST? And a bulk request might
> return erroneous results as well?
Correct. As no data is lost, this is a nuisance, less a problem.
> On that basis, should only PUTs be allowed, to protect users from an
> infrastructure bug they aren't aware of?
I've been thinking along these lines a few times now. This might be
worth considering, but I'm no convinced yet.
> Those lmgtfy links seem to be about the double post being triggered
> by the browser client, as opposed to e.g. a ruby client. I knew
> about that problem, but I've not seen a problem report due to
> *middleware* e.g. proxy/cache ignoring the non-idempotency of POST.
The point is that CouchDB can't know if requests come from a broken or
compliant middleware system with new ones coming up all the time.
Cheers
Jan
--
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 10:08 AM, Jan Lehnardt wrote:
>
> On 8 Mar 2009, at 00:22, Antony Blakey wrote:
>
>>
>> On 08/03/2009, at 4:41 AM, Chris Anderson wrote:
>>
>>> Currently it's recommended not to POST new documents without ids to
>>> CouchDB. Due to HTTP protocol issues this can result in duplicate
>>> document creation.
>>
>> I've never really understood this. Wouldn't it mean that all POST
>> operations in CouchDB need to be made idempotent by the server
>> because they might be erroneously repeated by middleware?
>
> Correct, a bug in Safari / CFNetwok brought this up.
I can't find a reference to a Safari/CFNetwork double post problem. Do
you have one? Will it become obsolete?
One implication of this is that a create or update might return a 412,
even though it has succeeded, because the client is seeing the
response from the second, repeated POST? And a bulk request might
return erroneous results as well?
On that basis, should only PUTs be allowed, to protect users from an
infrastructure bug they aren't aware of?
Those lmgtfy links seem to be about the double post being triggered by
the browser client, as opposed to e.g. a ruby client. I knew about
that problem, but I've not seen a problem report due to *middleware*
e.g. proxy/cache ignoring the non-idempotency of POST.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
Re: Please allow _prefix for auto-created _id
Posted by Jan Lehnardt <ja...@apache.org>.
On 8 Mar 2009, at 00:22, Antony Blakey wrote:
>
> On 08/03/2009, at 4:41 AM, Chris Anderson wrote:
>
>> Currently it's recommended not to POST new documents without ids to
>> CouchDB. Due to HTTP protocol issues this can result in duplicate
>> document creation.
>
> I've never really understood this. Wouldn't it mean that all POST
> operations in CouchDB need to be made idempotent by the server
> because they might be erroneously repeated by middleware?
Correct, a bug in Safari / CFNetwok brought this up.
> Given that POSTing to a collection, resulting in a response with a
> Location header is a fundamental part of the REST model, how do
> other REST APIS deal with this problem?
http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection&l=1
and more here:
http://lmgtfy.com/?q=rest+non+idempotent+POST+to+a+collection
Cheers
Jan
--
Re: Please allow _prefix for auto-created _id
Posted by Antony Blakey <an...@gmail.com>.
On 08/03/2009, at 4:41 AM, Chris Anderson wrote:
> Currently it's recommended not to POST new documents without ids to
> CouchDB. Due to HTTP protocol issues this can result in duplicate
> document creation.
I've never really understood this. Wouldn't it mean that all POST
operations in CouchDB need to be made idempotent by the server because
they might be erroneously repeated by middleware?
Given that POSTing to a collection, resulting in a response with a
Location header is a fundamental part of the REST model, how do other
REST APIS deal with this problem?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
If a train station is a place where a train stops, what's a workstation?
Re: Please allow _prefix for auto-created _id
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Mar 7, 2009 at 3:58 AM, Wout Mertens <wo...@gmail.com> wrote:
> Hi devs,
>
> Would it be possible to allow a _prefix parameter to be given when creating
> a new document, which would be used for auto-generating an _id?
Currently it's recommended not to POST new documents without ids to
CouchDB. Due to HTTP protocol issues this can result in duplicate
document creation.
Instead, GET /_uuids?count=200 and use the array of uuids for your
next 200 docs. From there it is simple to add the prefix in your
application.
Chris
--
Chris Anderson
http://jchris.mfdz.com