couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: associating UUIDs to DBs
Date Tue, 02 Feb 2010 05:16:55 GMT
On Mon, Feb 1, 2010 at 10:58 AM, Filipe David Manana <> wrote:
> Hi everybody,
> Recently there was a suggestion at #couchdb, involving me, Chris Anderson
> and Adam Kocoloski, about the possibility of adding UUIDs to a DB.
> It appeared in the context of a future _replications DB (which would store
> history about replication sessions, etc). It would not be desirable to
> replicate this DB into other nodes, otherwise it would mess up with their
> replication session history.
> It might not be desirable to accidentally replicate other system related DBs
> or user DBs (for some app specific reason).
> Then Chris suggested the possibility of adding a UUID to the DB. This UUID
> would be listed when doing a GET /somedb.
> At that moment I had to run and had no time to pose questions about this
> feature.
> I would like to understand it, have 1 or 2 example use cases, and figure out
> how it would impact the current code base, and code it.

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.

The replicator issue is how to detect whether 2 databases have a
replication history (because hostnames can change and people can rsync
files, it makes more sense to keep a uuid around).

It occurs to me that we could use the case of a matching uuid to
trigger fast-forward replication when block-level file duplicates come
online in a cluster.


> What I am thinking about is that a source DB which has a UUID associated
> with it, can not be replicated into a target DB unless the replication
> objects specifies the source's UUID.
> Example, for a DB testdb with UUID=qwerty
> POST /_replicate/
> { "source": "testdb", "target": "testdb_copy"}'
> Would fail, while doing:
> POST /_replicate/
> { "source":  "testdb",  "source_uuid":  "qwerty",  "target":  "testdb_copy"
> }
> To create a DB with a UUID, we would just use a query parameter to specifiy
> it, or use a boolean parameter to let couch generate it, for example. If
> none of these query parameters is given, the UUID is simply not generated.
> Now, I might have not understood completely what Chris and Adam have in
> mind, that's why I would like to collect some feedback from any of you.
> I think I'm missing something from the big picture.
> best regards,
> --
> Filipe David Manana,
> PGP key -
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."

Chris Anderson

View raw message