couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: associating UUIDs to DBs
Date Tue, 02 Feb 2010 07:55:39 GMT
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.


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message