couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: proposal: Using the db hooks in other databases
Date Wed, 04 Jan 2012 22:31:33 GMT
On Wed, Jan 4, 2012 at 11:11 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Wed, Jan 4, 2012 at 05:52, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> I've put a more readable and updated version here :
>>
>> https://github.com/refuge/refuge/wiki/DB-Security-hooks
>>
>> On Wed, Jan 4, 2012 at 10:52 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>> 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

Mime
View raw message