couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Heller <>
Subject Re: Mapping a Relation and include_docs
Date Sun, 19 Apr 2009 18:03:02 GMT
> Hmmm... I don't know how CouchDB gets those source document IDs. I suppose
> it would be nice to be able to say include_docs=field:userid so CouchDB
> would return the document with the ID equal to the value of the userid
> field.
> I'm interested in what the devs think of this... Devs?

pretty sure that this would require to parse/serialize the associated doc to
do the lookup (which would be slow/expensive), my "idea" would just store
another id along the already existing id. So in my head the doc lookup code
would look like doc:get(map_result.replace_id || I have no
idea what I'm talking about tho. ;)

>  The only Problem I have with my implementation is that a user is never
>> allowed to edit his own membership, only a group admin is allowed to do
>> that. So I have 2 different people editing the same Document and somehow
>> that feels dirty.
> But wouldn't a validation function be able to test for exactly these
> situations? If the change is proposed by a user then these fields are
> allowed to change, if a group admin then these fields...
> I suppose programming is a bit different from just saying "you have
> read-only access to this column" so I can understand your hesitation.
> Triple-check your validation functions I would say :)

Its not about validation its about handling the data. Currently I just hand
the complete user document over to the client and let him do whatever. He
sends it back and all I have to do is a simple post. Now when I cannot trust
him (he may fake himself into some super secret groups or somesuch) I have
to take the memberships array out of his data, fetch the right one from the
database, sync them and post it back. Plenty of places where stuff can go

Also my Idea is a pure optimization as the problem is already solved by
doing two simple get requests and I have no idea if it would be any
improvent on the server side.

Maybe some couchdb guru can tell me that I'm overthinking this stuff and
I'll stick to my all-in-one doc or seperate doc approached, whenever I can
decide which one I like more ;)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message