https://issues.apache.org/jira/browse/COUCHDB-1373
On Jan 26, 2012, at 2:30 PM, Jan Lehnardt wrote: > Hi Nick, > > this sounds useful. Would you mind posting the patch to a new JIRA issue? > > Cheers > Jan > -- > > On Dec 29, 2011, at 14:34 , Nick North wrote: > >> 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 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 >> 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 list, and would be grateful if someone could point >> me to the discussions so that I can understand the issues. Many thanks, >> >> Nick North >
