From dev-return-20104-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sat Jan 14 09:07:18 2012 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 AC85ABC3C for ; Sat, 14 Jan 2012 09:07:18 +0000 (UTC) Received: (qmail 17186 invoked by uid 500); 14 Jan 2012 09:07:17 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 16560 invoked by uid 500); 14 Jan 2012 09:07:06 -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 16543 invoked by uid 99); 14 Jan 2012 09:07:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Jan 2012 09:07:01 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_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, 14 Jan 2012 09:06:59 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 6761014C1FA for ; Sat, 14 Jan 2012 09:06:39 +0000 (UTC) Date: Sat, 14 Jan 2012 09:06:39 +0000 (UTC) From: "Nick North (Commented) (JIRA)" To: dev@couchdb.apache.org Message-ID: <495678129.40704.1326531999424.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= 186141#comment-13186141 ]=20 Nick North commented on COUCHDB-1373: ------------------------------------- Thanks - that looks pretty straightforward, except that the Erlang document= ation at http://www.erlang.org/doc/man/inet.html#getifaddrs-0 says that Sol= aris does not return a {hwaddr, _} tuple. But we can sort out some workarou= nd for that. I am about to go on holiday for three weeks, but can take a look at incorpo= rating the MAC address when I return, unless someone else wants to have a g= o in the interim. It might also be nice to give the user the option of spec= ifying a specific suffix if they want, or else give an interface name (and = then also have a sensible default if this algorithm is specified with neith= er a suffix nor an interface). =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: 0001-Add-etap-for-jira-1373.patch, 0002-utc_id_suffi= x.patch, 0003-utc_id_suffix.patch, couch_uuids.patch, utc_machine_id.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