As requested by Chris, and what I knew I should have just done to begin with (doh!): https://issues.apache.org/jira/browse/COUCHDB-477
On Mon, Feb 1, 2010 at 23:55, Randall Leeds <[email protected]> wrote: > Here's a patch. > > On Mon, Feb 1, 2010 at 22:02, Nicholas Orr <[email protected]> wrote: >> On Tue, Feb 2, 2010 at 4:16 PM, Chris Anderson <[email protected]> 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 >
