[
https://issues.apache.org/jira/browse/COUCHDB-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292866#comment-13292866
]
Paul Joseph Davis commented on COUCHDB-1495:
--------------------------------------------
More important than the dictionary lookup is the message passes between the
uuid gen_server and the requesting processes. Also important is that the
obvious gen_server:call implementation would eventually blow that gen_server
out of the water.
I think the idea is good and there are a number of other settings that people
have requested be database specific as well. The issue is that our config
system was never designed to be parameterized by the database name. There are
only one or two db specific options and those are stored in the database header
which means its not going to be a good way to scale out the db specific stuff.
So while there's been a decent number of requests for such a thing there hasn't
been a very good discussion on actually implementing generalized db specific
options. I'd think that figuring that out would be the larger priority so that
we don't have to have a specialized implementation for individual options.
> Allow the UUID algorithm to vary by database
> --------------------------------------------
>
> Key: COUCHDB-1495
> URL: https://issues.apache.org/jira/browse/COUCHDB-1495
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Affects Versions: 1.2
> Reporter: Nick North
> Priority: Minor
> Labels: uuid
>
> The UUID algorithm for generating document ids is currently a global setting,
> affecting all databases. When returning to
> https://issues.apache.org/jira/browse/COUCHDB-1373 after a long hiatus, I
> realised it might be useful to allow a default algorithm, with per-database
> overrides.
> I propose that the uuids section of the config be of the following form,
> modelled somewhat on the compactions section:
> algorithm = AlgorithmName
> overrides = [ {DatabaseName, AlgorithmName, [ { ParamName, ParamValue},
> {ParamName, ParamValue}, ...]},
> {DatabaseName, AlgorithmName, [ { ParamName, ParamValue},
> {ParamName, ParamValue}, ...]}, ...]
> The "algorithm" element is exactly as it now is, specifying the default UUID
> algorithm, to be used when the algorithm is not overridden and for responding
> to the _uuids HTTP request. It also gives backwards compatibility.
> The optional "overrides" element specifies algorithms for named databases,
> each with a list of algorithm-specific parameters. The list may be empty (or
> potentially absent altogether, which would have the same meaning as an empty
> list).
> The special database name _default is used to specify a default algorithm
> that needs parameters or instead or the "algorithm" element.
> Implementation would be by giving the couch_uuids gen_server a state
> consisting of a dictionary mapping database names to an {AlgorithmName,
> AlgorithmState} pair, where AlgorithmState is an algorithm-dependent value
> and the default algorithm is associated with database name _default. Requests
> for a UUID for a specific database would pass in the database name for use in
> determining the right algorithm. [This gives rise to a potential objection to
> the proposal, as there is a performance hit: every new document id requires a
> dictionary lookup of the database name, and possibly a second lookup of the
> _default entry if the name is not found; there may also be a dictionary
> insertion of the new AlgorithmState value. However, I suggest that is small
> compared to everything else that goes on when creating a document.]
> If people like this idea, I am happy to put forward some code, and wrap in
> the implementation of https://issues.apache.org/jira/browse/COUCHDB-1373,
> which I have neglected for far too long. The two proposals are not
> necessarily tied together, but implementing this one changes the
> implementation of the other so it is more convenient to do both together.
--
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
