You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Newson <ro...@gmail.com> on 2009/04/12 00:35:20 UTC
db-options
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?
B.
Re: db-options
Posted by Paul Davis <pa...@gmail.com>.
On Sat, Apr 11, 2009 at 8:20 PM, Chris Anderson <jc...@apache.org> wrote:
> On Sat, Apr 11, 2009 at 5:08 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Sat, Apr 11, 2009 at 7:23 PM, Chris Anderson <jc...@apache.org> wrote:
>>> On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <ro...@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.
>
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
> http://jchrisa.net
> http://couch.io
>
Re: db-options
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Apr 11, 2009 at 5:08 PM, Paul Davis <pa...@gmail.com> wrote:
> On Sat, Apr 11, 2009 at 7:23 PM, Chris Anderson <jc...@apache.org> wrote:
>> On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <ro...@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
Re: db-options
Posted by Paul Davis <pa...@gmail.com>.
On Sat, Apr 11, 2009 at 7:23 PM, Chris Anderson <jc...@apache.org> wrote:
> On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <ro...@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.
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>
Re: db-options
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Apr 11, 2009 at 3:35 PM, Robert Newson <ro...@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.
--
Chris Anderson
http://jchrisa.net
http://couch.io