couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <>
Subject Re: proposal: Using the db hooks in other databases
Date Wed, 04 Jan 2012 22:35:57 GMT
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

On Wed, Jan 4, 2012 at 10:31 PM, Benoit Chesneau <> wrote:
> On Wed, Jan 4, 2012 at 11:11 PM, Randall Leeds <> wrote:
>> On Wed, Jan 4, 2012 at 05:52, Benoit Chesneau <> wrote:
>>> I've put a more readable and updated version here :
>>> On Wed, Jan 4, 2012 at 10:52 AM, Benoit Chesneau <>
>>>> Hi all,
>>>> Following is a quick proposal to implement support of hooks to other
>>>> databases. Let me know what you think about it. I would be be happy to
>>>> start the work on that.
>> Thanks for getting this conversation going. I support the idea. You
>> and I discussed a database erlang behaviour and IIRC you did some work
>> on it. Did you go further? I wonder if a default behaviour is to
>> delegate to design docs and if any common behaviour module could
>> simplify code for _users, _replicator, and _design-based.
>> I am already getting too into implementation, though. +1 on the overall idea.
>> -Randall
> Thanks for the support.
> I've tried this idea of having an erlang behaviour for that indeed. To
> summarize, the idea was about having a module behaviour (in erlang
> meaning) exposing 4 erlang functions:
> - before_doc_update
> - after_doc_read
> - on_all_docs
> - on_changes
> The main problem after that was solving the association of this module
> or functions to a database. Main idea was having this association done
> in the ini file. Something like:
>    [security]
>    dbname = modulename
> After trying it I don't like so much this idea. The main advantage is
> the speed right now. But this doesn't give any power for the design
> doc writer and it may not be scalable when we speak about N dbs where
> N>1000 .
> On this other hand if such config is found in a db we have the
> following advantages:
> - replication of such rules
> - rules are now dynamic and can be changed easily, you just have to
> upload a new version of the design doc.
> The actual problem of such solution may be the speed of the JS
> processing if the functions are made in JS (same problem in
> validate_update though) . This problem can be solved later anyway by
> improving the JS engine.
> One other solution would be creating some kind of DSL evaluated in
> ERLANG like we do for the rewriter:
> Imo the idea of having functions in the design docs may be the simpler actually.
> - benoît

Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

View raw message