couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Neijt <>
Subject Re: Need feedback on validate_doc_read
Date Tue, 28 Dec 2010 19:50:54 GMT
Hi all,

First of all, thank you all for your replies. I've had a great lot of
fun working my way though Erlang, and I'm glad this patch may help in
clearing up the question on whether this is something that should be
on the CouchDB roadmap or not.

Robert is completely right in pointing out that this does not protect
views at all, (and I have not even tested it on show functions
either). Protecting a view is not really possible as that would
require a view per user/role, I can not think of any straight forward
way of implementing that. Using a database per user is a solution
here, because that forces a separate view cache as well.

I'll clean up the patch using the comments given, which should make it
possible for people to try the performance impact. I myself have never
really cared for the performance impact. IMHO performance will be met
as soon as the feature is accepted and used enough ;)

Anybody wanting this feature should test the performance impact and
convince as many people as possible!



On Tue, Dec 28, 2010 at 12:56 PM, Filipe David Manana
<> wrote:
> Hi Bram,
> I second what Paul and Robert said before.
> Here:
> You're assuming Else is always {_, Doc} tuple, which is wrong. It
> might be an error for e.g. You'll likely want to call
> validate_doc_read for couch_db:open_doc_revs/3.
> Overall I'm not sure this as a feature that CouchDB needs, but that's
> up to the community/PMCs to decide.
> Nevertheless, thanks for your efforts.
> On Mon, Dec 27, 2010 at 4:09 PM, Bram Neijt <> wrote:
>> Hi all,
>> After getting to know erlang the hard way, I've found a place to put
>> in a patch and hook up validate_doc_read code.
>> I've got a patch which implements a validate_doc_read in the same
>> manner as validate_doc_update is implemented. The patch is available
>> at
>> Things that are still on the TODO are the following:
>> - Check the functioning when it comes to replication
>> - Test the performance hit this will have on the server
>> - Create a configuration option to enable or disable support for this
>> An even bigger question is: is this a feature we would ever want in
>> the mainstream couchdb releases? Is this something the couchdb team
>> would like to support?
>> But appart from that question, I would love some feedback on the
>> implementation, the erlang and structure of it all, so please consider
>> checking it out and posting some comments.
>> Greets,
>> Bram
>> On Tue, Dec 7, 2010 at 1:18 PM, Bram Neijt <> wrote:
>>> Dear developers,
>>> After going into the theoretical depths[1] of what performance hits
>>> there may be and how replication will be affected, I've decided to
>>> just implement a simple solution and see how far I can get.
>>> I've decided to try to implement a validate_doc_get function, in the
>>> same manner as the validate_doc_update has been implemented. I've been
>>> reading the code and I've gotten as far as finding
>>> prep_and_validate_updates and handle_doc_show and I'm now thinking of
>>> copying and pasting some logic in to see where it gets me.
>>> I would love some advice on the matter and welcome any comments/feedback.
>>> Greets,
>>> Bram
>>> [1]
>>> PS If properly implemented, validate_doc_get will not fix all problems
>>> and you will still need a firewall like system, however it may give
>>> some insight into where to go from there.
> --
> 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