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? On Wed, Jan 4, 2012 at 10:31 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Wed, Jan 4, 2012 at 11:11 PM, Randall Leeds <randall.le...@gmail.com> > wrote: >> On Wed, Jan 4, 2012 at 05:52, Benoit Chesneau <bchesn...@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 <bchesn...@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 -- 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."
