couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Please allow _prefix for auto-created _id
Date Sun, 08 Mar 2009 03:05:04 GMT
On Sat, Mar 7, 2009 at 9:01 PM, Antony Blakey <> wrote:
> On 08/03/2009, at 11:43 AM, Chris Anderson wrote:
>> On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey <>
>> 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

> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
> Some defeats are instalments to victory.
> -- Jacob Riis

Paul Davis

View raw message