Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Sat, 31 Dec 2011 15:28:30 +0000 (UTC)
From: "Nick North (Created) (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1871537560.55901.1325345310659.JavaMail.tomcat@hel.zones.apache.org>
Subject: =?utf-8?Q?[jira]_[Created]_(COUCHDB-1373)_Time-order=E2=80=8Bed?=
 =?utf-8?Q?_document_ids_including_the_database_identity?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Time-order=E2=80=8Bed document ids including the database identity
----------------------------------------------------------

                 Key: COUCHDB-1373
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1373
             Project: CouchDB
          Issue Type: Improvement
          Components: Database Core
            Reporter: Nick North
            Priority: Minor


This suggestion is for an enhancement to the document id generation algorit=
hms in CouchDb. I am new to CouchDb, and this question addresses an old iss=
ue (https://issues.apache.org/jira/browse/COUCHDB-465) so please forgive me=
 if I am retreading old ground.

My application has a number of mutually replicating CouchDb instances and I=
 would like document ids to be monotonically-increasing per-instance, and g=
lobally unique, and for the instance where the document was created to be d=
eterminable from the id. (To be more accurate - I don't need to know anythi=
ng about the instance itself; just whether any two documents originated fro=
m the same instance.) The utc_random algorithm is not far from meeting thes=
e requirements, as ids are monotonic and almost certainly globally unique. =
However, the instance cannot be determined from the id, and there is a tiny=
 chance of an id clash between two instances. Both of these issues could be=
 solved if the random part of the id could be replaced with a suffix that i=
s fixed in the ini file for each instance.

To addresses this I have a modified version of couch_uuids.erl introducing =
a new utc_machine_id algorithm which reads a machine_id string from the ini=
 file and then generates ids using an internal utc_suffix method that just =
appends the string to the usual utc 14-byte string. utc_random then also us=
es the utc_suffix method, but its suffix is the usual random byte string.

However, it is obviously a nuisance to have to maintain a non-standard dist=
ribution, so I wondered if there is enough call for this sort of thing to m=
ake it a part of the standard distribution? If there is, I'd be very happy =
to make my code available for discussion/modification/inclusion. If there a=
re good reasons why this is a bad idea, then I'd also be very interested to=
 hear them so that I can rethink my ideas. (It happens that the privacy and=
 guessability concerns raised in the original discussion do not apply in my=
 case.) If this question has been beaten to death, then I'm sorry for bothe=
ring the group, and would be grateful if someone could point me to the disc=
ussions so that I can understand the issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira