Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.218.218 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=CtZrKrbJ+niOsr2AEDIY9rX5tL6lLxY7J1urKs5xQzXv6aA13f4xrMJzKSzhl6QWh6
         lkkvLfX/QKtEPsvnHxTVmwX0VO28YpBX1zObxiJr6vcEcl/IKnZWoy0oIyZV3bPE+FAA
         gm67ZHlMbx800DN5St+76JIqmLdod6WGDAUC8=
MIME-Version: 1.0
In-Reply-To: <46aeb24f1002011238y42a0f7ffkde1c750700e0031f@mail.gmail.com>
References: <cadf1c691002011058r1cf1fbfbk45a41db9ea3932f7@mail.gmail.com>
	 <46aeb24f1002011238y42a0f7ffkde1c750700e0031f@mail.gmail.com>
Date: Mon, 1 Feb 2010 13:06:57 -0800
Message-ID: <ec7a93a1002011306s1757b2c2k7c93b6dc2a5973df@mail.gmail.com>
Subject: Re: associating UUIDs to DBs
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Cc: fdmanana@gmail.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've been thinking about UUIDs for DBs myself. I see a couple cases
where this could come in handy. Both involve replication:

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

2)
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
UUID.

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.

-Randall

P.S. Will work for alcohol.

On Mon, Feb 1, 2010 at 12:38, Robert Newson <robert.newson@gmail.com> 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 <fdmanana@gmail.com> =
wrote:
>> Hi everybody,
>>
>> Recently there was a suggestion at #couchdb, involving me, Chris Anderso=
n
>> and Adam Kocoloski, about the possibility of adding UUIDs to a DB.
>>
>> It appeared in the context of a future _replications DB (which would sto=
re
>> history about replication sessions, etc). It would not be desirable to
>> replicate this DB into other nodes, otherwise it would mess up with thei=
r
>> 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 UU=
ID
>> 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=3Dqwerty
>>
>> POST /_replicate/
>> { "source": "testdb", "target": "testdb_copy"}'
>>
>> Would fail, while doing:
>>
>> POST /_replicate/
>> { "source": =C2=A0"testdb", =C2=A0"source_uuid": =C2=A0"qwerty", =C2=A0"=
target": =C2=A0"testdb_copy"
>> }
>>
>> To create a DB with a UUID, we would just use a query parameter to speci=
fiy
>> 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 generate=
d.
>>
>> 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=3Dget&search=3D0xC56945=
2B
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>