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
