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 Mon, 01 Feb 2010 21:06:57 GMT
I've been thinking about UUIDs for DBs myself. I see a couple cases
where this could come in handy. Both involve replication:

IIRC, pull replication with an "http://..." (but local!) target and a
plain "dbname" target do not share checkpoints. Using a UUID would
allow CouchDB to easily identify whether it is pulling to a local
database even if the target specifies a URI and even if hostname
report's something other than the domain of the URI.

If replication checkpoints store the UUID of the database the changes
were read from it would allow CouchDB to replicate checkpoints. For
example, imagine a continuous bi-directional replication between nodes
A and B. Now, add node C to the group and replicate from B to C. If we
then set up replication between A and C, C would not have to scan all
of A's changes because it is already aware of the checkpoints B made
when replicated from A by comparing its checkpoint source UUIDs to A's

I can't claim to understand the internals of the replication code very
well (yet...), but I believe my claims to be correct and welcome
anyone who knows better to step in and say otherwise. Assuming I got
my facts straight, I'd love to see this for 0.11, as well as a
replications db for continuous replications that survive restarts. Oh,
and replication based on _changes.


P.S. Will work for alcohol.

On Mon, Feb 1, 2010 at 12:38, Robert Newson <> wrote:
> can't you make a _local document with your own unique identifier?
> _local documents are not replicaed.
> B.
> On Mon, Feb 1, 2010 at 6:58 PM, 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.
>> 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."

View raw message