Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <5375C93B.3070209@nospam.yrnm.net>
Date: Fri, 16 May 2014 10:15:55 +0200
From: Franck Eyraud <franck+couchdbml@nospam.yrnm.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Are these in Plugin scope?
References: 
 <CABadZm+PzA2qXnWfG8LwB_-tr9vN9MKeMgVbFFQkYkOJ+an7kQ@mail.gmail.com>
 <266B09EF-0542-47E8-9CEE-8E6B068559E5@utt.fr>
In-Reply-To: <266B09EF-0542-47E8-9CEE-8E6B068559E5@utt.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 13/05/2014 22:30, Aurélien Bénel a écrit :
> Hi Suraj,
>
>> 1. Audit keeping: set a mandatory (potentially configurable) field in each
>> doc with the UserCtx.name and Date/Time. (like, "last_modified_time" =
>> current_time and "last_modified_by" = UserCtx.name).
>> 2. Audit trail: whenever docs are created/updated, also write another
>> "snapshot" doc for history keeping.
> I might have misunderstood what you wanted to achieve but couldn't you do that with a simple update handler?
Interesting question; can the list confirm these statements :

1. can be done with a simple update handler
2. cannot because it requires the creation of an extra doc (since 
couchdb revisions can not be considered for history keeping, one of the 
reason is that they don't survive replication)

This plugin subject seems very interesting to me, but it is 
unfortunately not very discussed in the mailing list.

Le 13/05/2014 14:29, Suraj Kumar a écrit :
>  From what I understand, plugins work at the HTTP layer only and not at the
> DB layer.
It is almost true, except that you can also plug in in the 
authentication layer.
I suppose that allowing the plugins to intervene at the dB layer would 
complicate much the db engine as trust would not be the same; but the 
plugin system is currently quite new, and might evolve.

> Are these two features in Plugin scope?
Currently from what I know (but I'm a mere user that looked as you did), 
yes they are out of scope.

> If not, what is the "right" way of
> doing this? (Two options I see: 1. introduce a middle ware layer 2.
> continue to hack couchdb-erlang code and maintain it ourselves*). Any other
> options?
One another solution might be some extra services listening for changes 
(in node.js for example), and making the desired modifications.

Franck