From dev-return-19910-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Jan 4 22:32:00 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6EA92B6BA for ; Wed, 4 Jan 2012 22:32:00 +0000 (UTC) Received: (qmail 22661 invoked by uid 500); 4 Jan 2012 22:31:59 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 22632 invoked by uid 500); 4 Jan 2012 22:31:59 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 22624 invoked by uid 99); 4 Jan 2012 22:31:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 22:31:59 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 22:31:54 +0000 Received: by eeke52 with SMTP id e52so18101128eek.11 for ; Wed, 04 Jan 2012 14:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=eQKwuUjSziHsaDKTTicTomm6E0GAO4dmYY9ZFqIck6I=; b=ek1KlVV7+hMF/cE8eEAl73ynhcg2vVxBrHqBTwO74ESvkTqEqTbvgl6D2ghOka8i9a J1V/DWDeA38VbPCD1I1sc2LXhdHoOd9mHwlSWxg7qQsGENZNDcgKoo/C8mU/2IXEw0MK R4BIBlAf9XNtjFlBPPeQlPZ9UMJVH49wsFwrc= MIME-Version: 1.0 Received: by 10.213.29.197 with SMTP id r5mr4455114ebc.122.1325716293261; Wed, 04 Jan 2012 14:31:33 -0800 (PST) Received: by 10.213.15.139 with HTTP; Wed, 4 Jan 2012 14:31:33 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Jan 2012 23:31:33 +0100 Message-ID: Subject: Re: proposal: Using the db hooks in other databases From: Benoit Chesneau To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 4, 2012 at 11:11 PM, Randall Leeds wr= ote: > On Wed, Jan 4, 2012 at 05:52, Benoit Chesneau 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 w= rote: >>> 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 i= dea. > > -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 =3D 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 actu= ally. - beno=EEt