From dev-return-19889-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sat Dec 31 23:21:58 2011 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E47BCBD5E for ; Sat, 31 Dec 2011 23:21:57 +0000 (UTC) Received: (qmail 72649 invoked by uid 500); 31 Dec 2011 23:21:57 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 72572 invoked by uid 500); 31 Dec 2011 23:21:57 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 72564 invoked by uid 99); 31 Dec 2011 23:21:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Dec 2011 23:21:57 +0000 X-ASF-Spam-Status: No, hits=-2001.3 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Dec 2011 23:21:51 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id AA694132717 for ; Sat, 31 Dec 2011 23:21:30 +0000 (UTC) Date: Sat, 31 Dec 2011 23:21:30 +0000 (UTC) From: "Paul Joseph Davis (Commented) (JIRA)" To: dev@couchdb.apache.org Message-ID: <812606156.56273.1325373690699.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1871537560.55901.1325345310659.JavaMail.tomcat@hel.zones.apache.org> Subject: =?utf-8?Q?[jira]_[Commented]_(COUCHDB-1373)_Time-order=E2=80=8Be?= =?utf-8?Q?d_document_ids_including_the_database_identity?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-1373?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13= 178095#comment-13178095 ]=20 Paul Joseph Davis commented on COUCHDB-1373: -------------------------------------------- Your whitespace is wonky. Indentation in Erlang code should be four spaces = and not tabs. There's also some pure white-space changes. Also, you should add a note in the default.ini.tpl.in file to indicate that= the new algorithm exists as well as the fact that it requires the couchdb/= machine_id setting to do what it's supposed to. I'm also hesitating if mach= ine_id shouldn't be in the uuid section or not. Not super important but I f= ind it a bit odd to have it there. Also, I wonder if it'd be possible to generate some sort of default machine= id if one isn't specified. Something like, a sha of all mac addresses in s= orted order? Then again I'm not sure how hard it'd be to get that list from= Erlang in a portable fashion. =20 > 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 > Labels: uuid > Attachments: couch_uuids.patch > > > This suggestion is for an enhancement to the document id generation algor= ithms in CouchDb. I am new to CouchDb, and this question addresses an old i= ssue (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= globally unique, and for the instance where the document was created to be= determinable from the id. (To be more accurate - I don't need to know anyt= hing about the instance itself; just whether any two documents originated f= rom the same instance.) The utc_random algorithm is not far from meeting th= ese requirements, as ids are monotonic and almost certainly globally unique= . However, the instance cannot be determined from the id, and there is a ti= ny 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= is fixed in the ini file for each instance. > To address 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 di= stribution, so I wondered if there is enough call for this sort of thing to= make it a part of the standard distribution? If there is, I'd be very happ= y to make my code available for discussion/modification/inclusion. If there= are 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 a= nd 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 bot= hering the group, and would be grateful if someone could point me to the di= scussions 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