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 237E298A9 for ; Mon, 11 Jun 2012 09:17:46 +0000 (UTC) Received: (qmail 20593 invoked by uid 500); 11 Jun 2012 09:17:45 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 20007 invoked by uid 500); 11 Jun 2012 09:17:44 -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 19447 invoked by uid 99); 11 Jun 2012 09:17:42 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2012 09:17:42 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id AE73D14002F for ; Mon, 11 Jun 2012 09:17:42 +0000 (UTC) Date: Mon, 11 Jun 2012 09:17:42 +0000 (UTC) From: "Nick North (JIRA)" To: dev@couchdb.apache.org Message-ID: <448272090.2336.1339406262716.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Created] (COUCHDB-1495) Allow the UUID algorithm to vary by database MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Nick North created COUCHDB-1495: ----------------------------------- Summary: 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 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