couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Please allow _prefix for auto-created _id
Date Sun, 08 Mar 2009 02:01:48 GMT

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.

>> 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

View raw message