Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.219.166 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=wZGSRZeYJAMLFHioUDnKYy+8OnsxwEKAFYQ0vpGZl17C9A2Y2w9lYHZYRf+KRYlc+Q
         uUOgWk0yZfGdyphyDGeIgQ3vZv6N6rUPC0vK6SuiEA3cxqhkjqJS0NdOn6tzDiFTmDaz
         jv0ICguXrAkEVWJmWRJkIbwn5lTtEcPyzaV8g=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <e2111bbb0904111708g2232b048p97f123b6253f351a@mail.gmail.com>
References: <46aeb24f0904111535w12dbad5t667065897a8560b1@mail.gmail.com>
	 <e282921e0904111623t2118ae62k780c39460fcdca49@mail.gmail.com>
	 <e2111bbb0904111708g2232b048p97f123b6253f351a@mail.gmail.com>
Date: Sat, 11 Apr 2009 17:20:30 -0700
Message-ID: <e282921e0904111720w6e018336y136ffdb6a2a4e7dd@mail.gmail.com>
Subject: Re: db-options
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sat, Apr 11, 2009 at 5:08 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Sat, Apr 11, 2009 at 7:23 PM, Chris Anderson <jchris@apache.org> wrote:
>> On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <robert.newson@gmail.com> wrote:
>>> Devs,
>>>
>>> Following a brief discussion on IRC, I wanted to hear general thoughts
>>> and objections to introducing creation-time database options. That is,
>>> allow couchdb databases to toggle some features on or off on a
>>> per-database basis. Additionally, these options could be changed at
>>> compaction time.
>>>
>>> The first concrete example of such an option would be a feature that
>>> introduces single-instance storage of attachments. Namely, the
>>> addition of another btree keyed on the sha1 evaluation of attachments.
>>> The tree would be used to ensure only one copy of any particular
>>> attachment exists in the database file. This option could be added or
>>> removed during compaction also.
>>>
>>> Thoughts?
>>
>> I think this is a great idea. I'd suggest keeping the db-options in
>> the #db_header record. Which could get problematic if there get to be
>> so many options that the header size starts to grow. Maybe there's a
>> better answer, but this seems most straightforward.
>>
>
> There's also _local/ documents so that changes to config options don't
> cause binary incompatibilities.
>
>>

We don't want the binary storage mechanism to be able to change except
at the beginning of compaction. So for these types of config it should
be baked into the file. Otherwise editing the _local/db-config doc
could corrupt your database.

There are a class on configs that could go in local docs, but most of
those seem better suited for local.ini (imagine an auto-compaction
setting or the rev-stemming threshold).

-- 
Chris Anderson
http://jchrisa.net
http://couch.io