On Tue, Aug 16, 2011 at 11:46 AM, Filipe David Manana <[email protected]> wrote: > On Tue, Aug 16, 2011 at 2:38 AM, Benoit Chesneau <[email protected]> wrote: >> On Tue, Aug 16, 2011 at 11:30 AM, Filipe Manana (JIRA) <[email protected]> >> wrote: >>> >>> [ >>> https://issues.apache.org/jira/browse/COUCHDB-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085605#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 applied. >> >> 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
