Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 87430 invoked from network); 2 Feb 2010 06:03:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Feb 2010 06:03:29 -0000 Received: (qmail 75168 invoked by uid 500); 2 Feb 2010 06:03:29 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 74957 invoked by uid 500); 2 Feb 2010 06:03:28 -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 74947 invoked by uid 99); 2 Feb 2010 06:03:28 -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 06:03:28 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.223.200] (HELO mail-iw0-f200.google.com) (209.85.223.200) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 06:03:21 +0000 Received: by iwn38 with SMTP id 38so2767652iwn.11 for ; Mon, 01 Feb 2010 22:03:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.161.69 with SMTP id q5mr3635796ibx.57.1265090579062; Mon, 01 Feb 2010 22:02:59 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Feb 2010 17:02:59 +1100 Message-ID: <55047b711002012202j1878120epfb6a34629fcb812b@mail.gmail.com> Subject: Re: associating UUIDs to DBs From: Nicholas Orr To: dev Content-Type: multipart/alternative; boundary=0050450158d792df3e047e97da87 --0050450158d792df3e047e97da87 Content-Type: text/plain; charset=ISO-8859-1 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. > > 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 have run into this and it was most confusing. I'd destroy create the database, add the same ddocs and create some new docs and I'd see the doc _id from before in the browser. very annoying - then I figured out the browser was caching stuff, so now I use ctrl+f5 in firefox to actually refresh the data on the screen... --0050450158d792df3e047e97da87--