couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
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 <fdmanana@gmail.com> 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.

Chris



> 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,
> fdmanana@gmail.com
> PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
>
> "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
http://jchrisa.net
http://couch.io

Mime
View raw message