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. > > 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...
