couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: db-options
Date Sun, 12 Apr 2009 00:20:30 GMT
On Sat, Apr 11, 2009 at 5:08 PM, Paul Davis <> wrote:
> On Sat, Apr 11, 2009 at 7:23 PM, Chris Anderson <> wrote:
>> On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <> 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

View raw message