couchdb-dev mailing list archives

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

Touché. Also, there's ways to add that to the binary format without
breaking binary compatibility anyway.

> 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