Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.215.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAL3q7H7s0XFNT05d+-aDGZ0YRAcQPXkNFQ_56VTqkYZJaXpxqg@mail.gmail.com>
References: 
 <695819657.34335.1305020883141.JavaMail.tomcat@hel.zones.apache.org>
	<718059633.40893.1313487028462.JavaMail.tomcat@hel.zones.apache.org>
	<CAJNb-9qVxyWTpUCJvEFRV-oy3DEYdNTto-_Ns__X2ZOMHT+r5Q@mail.gmail.com>
	<CAL3q7H7s0XFNT05d+-aDGZ0YRAcQPXkNFQ_56VTqkYZJaXpxqg@mail.gmail.com>
Date: Tue, 16 Aug 2011 11:58:15 +0200
Message-ID: 
 <CAJNb-9p4JStsxC1WwzSNaZROYf+J3qG=bh0QLCXogSmyJDaXqg@mail.gmail.com>
Subject: Re: [jira] [Commented] (COUCHDB-1153) Database and view index
 compaction daemon
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16, 2011 at 11:46 AM, Filipe David Manana
<fdmanana@apache.org> wrote:
> On Tue, Aug 16, 2011 at 2:38 AM, Benoit Chesneau <bchesneau@gmail.com> wr=
ote:
>> On Tue, Aug 16, 2011 at 11:30 AM, Filipe Manana (JIRA) <jira@apache.org>=
 wrote:
>>>
>>> =A0 =A0[ https://issues.apache.org/jira/browse/COUCHDB-1153?page=3Dcom.=
atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedComment=
Id=3D13085605#comment-13085605 ]
>>>
>>> Filipe Manana commented on COUCHDB-1153:
>>> ----------------------------------------
>>>
>>> I'm -1 on adding such a _meta thing.
>>
>> why?
>
> From your description, that _meta sounds like something that can be
> done with _local docs. But that is a whole separate discussion and
> topic I think.
>

Could be a local docs, But why didn't we took this path for this
"_security" object ? Also since they are really "meta" informations,
i've the feeling it should be solved as a special member in the db
file, just like the "_security" object.

Anyway what I really dislike is saving per db configuration in an ini
file. Per db configuration should be done on the db. What if you more
than 100 dbs. Having 100 lines in an ini file to parse is awkward.
meta informations (like security, db params, ...) should be saved in
the db file and available in the same time. Since we have already this
_security object that is available when you open why not reusing it ?

>>
>>
>>> I don't understand either that idea of _changes nor how it can be appli=
ed.
>>
>> creating db, adding db document to dbs db., update -> update db document=
.
>
> You'll have to elaborate a lot more than that :) I'm not familiar with
> that bigcouch special db nor elasticsearch.
>
> Reacting to a changes feed of some database it's not something easy
> (the _replicator db is such a case and might have been the hardest
> thing i did ever for couch, really)
>


This is just as simple as this line, creating a db create an entry in
a db index (or db file) that you can use later.

> I suspect what you think is something like rather than scanning
> periodically, to let the daemon be notified when a db (or view) can be
> compacted?
> At some point I considered reacting to db_updated events but this was
> pretty much flooding the the event handler (daemon).
> Was this your idea?
>

Using db events is my idea yes.  If t actually flood the db event
handler (not sure why), then maybe we should fix it first?

- benoit