[
https://issues.apache.org/jira/browse/COUCHDB-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178038#comment-13178038
]
Bob Dionne commented on COUCHDB-1373:
-------------------------------------
Nick,
This seems reasonable, I'm sure there might be some issues to consider but if
it's done the way the others were I don't see why not. I've run into this sort
of thing before in systems where you want unique ids with a certain provenance
so you assign each player an additional unique id that becomes part of the
generated keys.
couch_uuids is a gen_server whose state is determined by an algorithm defined
in the config file. I see no problem with adding another. If you could submit a
patch it would be easier to assess or better yet a link to a source repo.
Best,
Bob
> 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
>
> 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
