Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 14029 invoked from network); 8 Mar 2009 00:45:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Mar 2009 00:45:21 -0000 Received: (qmail 69527 invoked by uid 500); 8 Mar 2009 00:45:20 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 69489 invoked by uid 500); 8 Mar 2009 00:45:20 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 69477 invoked by uid 99); 8 Mar 2009 00:45:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Mar 2009 16:45:19 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.68.5.15] (HELO relay01.pair.com) (209.68.5.15) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 08 Mar 2009 00:45:09 +0000 Received: (qmail 82308 invoked from network); 8 Mar 2009 00:44:46 -0000 Received: from 96.33.90.152 (HELO ?192.168.1.195?) (96.33.90.152) by relay01.pair.com with SMTP; 8 Mar 2009 00:44:46 -0000 X-pair-Authenticated: 96.33.90.152 Message-Id: From: Damien Katz To: dev@couchdb.apache.org In-Reply-To: <01672969-8B79-4220-92AD-82D7A5640091@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Please allow _prefix for auto-created _id Date: Sat, 7 Mar 2009 19:44:46 -0500 References: <8E00D3FC-52B5-40BC-9DA4-2D2F3580C22B@gmail.com> <3436ABAD-1FD6-408B-81CA-B1F17B151F97@apache.org> <01672969-8B79-4220-92AD-82D7A5640091@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on 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