From dev-return-8441-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 02 07:56:08 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 23954 invoked from network); 2 Feb 2010 07:56:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Feb 2010 07:56:08 -0000 Received: (qmail 35457 invoked by uid 500); 2 Feb 2010 07:56:08 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 35382 invoked by uid 500); 2 Feb 2010 07:56:08 -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 35372 invoked by uid 99); 2 Feb 2010 07:56:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 07:56:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com designates 209.85.218.218 as permitted sender) Received: from [209.85.218.218] (HELO mail-bw0-f218.google.com) (209.85.218.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 07:56:01 +0000 Received: by bwz10 with SMTP id 10so914047bwz.35 for ; Mon, 01 Feb 2010 23:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=V9W72T3VWtMphBlJ4KPPgDK/SM19itsw3cnBAQAdjMY=; b=CuxJSutnZg9yAdo2OKm/3YwaLTdJp04E9eFK+75kY5CNjs2Ao++WebuLX9gF9lkRnN v1Q9iVzUkT1OeK+5VBvMMZCzlHeDzqW4EbDqfaNk8cHgQ9EV76gd4xw9GdmBGr6EjrIf w9KiovZljwKZ+WB1awqrzAsHxumrRW+INLjWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZNu1I44qRmXsa6ZyGKqHb/nELrd0qkLajZ5nXcYOMmsbS40XXcBn7v/TRCpfqR4MVQ VYPeDxUv/CjESloynU26kaEMajsabrwDv7xAv/fJJ8UTKhGkCTNlk2WPY48cOrcgjtlv MkeA2pMTgcr4JEg7kDK7uGFD/1Kpi0/yMv7bw= MIME-Version: 1.0 Received: by 10.204.144.86 with SMTP id y22mr4080046bku.43.1265097339181; Mon, 01 Feb 2010 23:55:39 -0800 (PST) In-Reply-To: <55047b711002012202j1878120epfb6a34629fcb812b@mail.gmail.com> References: <55047b711002012202j1878120epfb6a34629fcb812b@mail.gmail.com> Date: Mon, 1 Feb 2010 23:55:39 -0800 Message-ID: Subject: Re: associating UUIDs to DBs From: Randall Leeds To: dev@couchdb.apache.org Content-Type: multipart/mixed; boundary=0015174bf0e08239a0047e996d16 --0015174bf0e08239a0047e996d16 Content-Type: text/plain; charset=UTF-8 Here's a patch. On Mon, Feb 1, 2010 at 22:02, Nicholas Orr wrote: > On Tue, Feb 2, 2010 at 4:16 PM, Chris Anderson wrote: > >> UUIDs will be useful for a lot of things. My favorite bug we see now >> from not having a uuid, is when you are prototyping an app in the >> browser (with a function to generate X random docs for testing): >> >> When you apply the same number of randomized edits to a db, that has >> the same view code each time, the browser will occasionally present >> data from previous runs. I added a test to etags_view.js that exercises this, both with a design document view and _all_docs. >> >> This is because the Etag function does not have a database UUID for >> input (only the sequence number, and the ddoc signature) so after n >> edits with the same code you have the same Etag. The easiest fix for >> this is to generate a random uuid on database creation, and factor it >> into the Etag function. I stored the uuid in the database header. Doing this made the patch really simple since couch will upgrade the database format without any additional code and provide the uuid in the /db_name response object. I'd like to take a crack at making replication take advantage of this information, but for now it could still be useful for clients or frameworks to interact with the uuid so I'm submitting just this for your review. Comments welcome, but it seems pretty straightforward. I have this nagging feeling there are people who might be uneasy with the idea of putting more things in the database header, but this was by far the cleanest way I could see to do this. Randall --0015174bf0e08239a0047e996d16--