From dev-return-10224-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sat Jun 12 15:48:57 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 46328 invoked from network); 12 Jun 2010 15:48:57 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Jun 2010 15:48:57 -0000 Received: (qmail 37395 invoked by uid 500); 12 Jun 2010 15:48:57 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 37315 invoked by uid 500); 12 Jun 2010 15:48:56 -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 37307 invoked by uid 99); 12 Jun 2010 15:48:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Jun 2010 15:48:56 +0000 X-ASF-Spam-Status: No, hits=2.7 required=10.0 tests=AWL,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.180] (HELO mail-wy0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Jun 2010 15:48:51 +0000 Received: by wyg36 with SMTP id 36so2548962wyg.11 for ; Sat, 12 Jun 2010 08:48:28 -0700 (PDT) Received: by 10.216.91.7 with SMTP id g7mr498320wef.93.1276357708399; Sat, 12 Jun 2010 08:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.22.77 with HTTP; Sat, 12 Jun 2010 08:48:08 -0700 (PDT) In-Reply-To: References: <20100612112432.GA9377@two> From: Jason Smith Date: Sat, 12 Jun 2010 22:48:08 +0700 Message-ID: Subject: Re: Auto-UUID generation in _update [PATCH] To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e68fa334d0c60b0488d72ffd --0016e68fa334d0c60b0488d72ffd Content-Type: text/plain; charset=UTF-8 On Sat, Jun 12, 2010 at 22:18, Paul Bonser 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 --0016e68fa334d0c60b0488d72ffd--