On Wed, Jan 4, 2012 at 11:55 PM, Filipe David Manana <fdman...@apache.org> wrote: > On Wed, Jan 4, 2012 at 10:38 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: >> On Wed, Jan 4, 2012 at 11:35 PM, Filipe David Manana >> <fdman...@apache.org> wrote: >>> While the use case for the system databases is clear, I wonder what >>> are the possible motivations to do it for regular databases. >>> >>> Does anyone has real world scenarios/examples where this level of >>> customization is useful and can't be done with the existing >>> infrastructure? >>> >>> >> Yes, read my example. > > Ok, I see. > > I wonder if adding on_changes and on_all_docs isn't a bit too much > complicated from a user's point of view.
This si the only way imo to make sure that the final user, for example, can't see all docs or changes. We already use such trick for _replicator and _users dbs. The complication can be removed anyway if we make all these functions optional and provide sane defaults. > Following that reasoning, there should be a "on_view_with_include_docs_true". I don't think there is a need for that. In fact a a design document is a document like the others. Since it's always opened by `_design` functions, views and others are already handled in before_update/after_read. > > The after_read_doc callback should work for these 3 cases when > ?include_docs=true is specified. > Sure, but include_docs is a special case. - benoît
