[ https://issues.apache.org/jira/browse/COUCHDB-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick North updated COUCHDB-1373: -------------------------------- Attachment: utc_machine_id.patch Thanks for the comments. Whitespace is now fixed, I've commented default.ini.tpl.in, and moved machine_id to the uuids section of the file as that's less intrusive. Revised patch attached as utc_machine_id.patch. > Time-ordered 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, utc_machine_id.patch > > > This suggestion is for an enhancement to the document id generation > algorithms in CouchDb. I am new to CouchDb, and this question addresses an > old issue (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 > anything about the instance itself; just whether any two documents originated > from the same instance.) The utc_random algorithm is not far from meeting > these 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 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 uses > 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 > distribution, 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 happy > 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 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 > bothering the group, and would be grateful if someone could point me to the > discussions 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 administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira