The usual way that's done is talked about here in the "One to Many"
section: http://wiki.apache.org/couchdb/EntityRelationship
Basically, you map function would be something like:
function(doc) {
if (doc.type == 'user') emit([0, doc._id], null);
else if (doc.type == 'asset') emit([1, doc.ownerid], null);
}
Then if you want to get the user and the assets they own, you would
query the view with startkey=[0, {userid}] and endkey=[1, {userid}],
and if you just want the list of assets owned by a certain user, you
use a startkey and endkey of [1, {userid}].
On Fri, Jun 25, 2010 at 11:40 AM, Sean Coates <[email protected]> wrote:
> ("subquery" for lack of a better term)
> (Apologies if this is a duplicate message. I subscribed in the wrong order.)
>
> Hello.
>
> I asked this in #CouchDB, but Jan suggested I also email it here.
>
> I have a problem where I have data in couch, and I want to perform what seems
> like one too many leaps of logic from within a view. Here's some sample data:
>
> [
> {"_id":1,"_rev":1,"type":"user","following":[2,3]},
> {"_id":2,"_rev":1,"type":"user","following":[1]},
> {"_id":3,"_rev":1,"type":"user","following":[1]},
> {"_id":4,"_rev":1,"type":"asset","ownerid":1},
> {"_id":5,"_rev":1,"type":"asset","ownerid":1},
> {"_id":6,"_rev":1,"type":"asset","ownerid":2},
> {"_id":7,"_rev":1,"type":"asset","ownerid":3},
> {"_id":8,"_rev":1,"type":"asset","ownerid":3}
> ]
> I want to query for a given id where type=user, and get all type=asset
> records owned by that user, or by users that the queried user is following.
> Here are some examples that hopefully help:
>
> _id=1; want documents with IDs: [4,5,6,7,8]
> _id=2; want documents with IDs: [4,5,6]
> _id=3; want documents with IDs: [4,5,7,8]
> I hope that's clear enough. if not, please let me know, and I'll try to
> expand my explanation.
>
> The foundation of the problem seems to be that from within a map, I can't
> fetch secondary type=user documents in order to perform what amounts to a
> join (in SQL-speak).
>
> Any help is appreciated. I'm currently solving this problem on the app side,
> but that's far from ideal (causes a mess with things like limits, for
> example).
>
> S
>
>
--
Paul Bonser
http://probablyprogramming.com
