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 08:07:25 GMT
As requested by Chris, and what I knew I should have just done to
begin with (doh!):

On Mon, Feb 1, 2010 at 23:55, Randall Leeds <> wrote:
> 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

View raw message