couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "EntityRelationship" by WoutMertens
Date Mon, 13 Apr 2009 22:06:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by WoutMertens:

The comment on the change is:
better views

  You would use this method when there is potentially a large number of contacts in a group
'''and''' a large number of groups. In that case embedding a list of keys could result in
huge documents so we have to resort to writing out the list in many documents.
- If you then want to know who is in a group you'll need to use the view
+ If you then want to know who is in a group you'll need to use the view (fetch descending
to get the group info first)
  "map":function(doc) {
     if (doc.type == 'relationship') {
+    } else if (doc.type == 'group') {
+       emit(doc._id,doc);
- To know what groups a contact belongs to you need to use
+ To know what groups a contact belongs to you can use
  "map":function(doc) {
     if (doc.type == 'relationship') {
-       emit(doc.contact_id,doc.group_id);
+       emit([doc.contact_id,1],doc.group_id);
+    } else if (doc.type == 'contact') {
+       emit([doc._id,0],doc);
+ Note that this view uses key arrays to enforce sorting, just to show you the possible variations.
The disadvantage is that you can't use ''key="Scott"'' to search for Scotts groups, you need
to use ''startkey=["Scott"]&endkey=["Scott",{}]''.
- As you can see, to retrieve further information about the group or the contact, you'll need
to send another query to CouchDB.
+ Unlike the previous method, you can't use ''include_docs=true'' now to get all information
about the contacts that are in a group or the groups that a contact has. The reason is that
the original documents that were used in generating the view are not the contact or group
documents, they are the relationship documents. If you want that information, you'll have
to fetch it separately.
+ If this is becoming a problem due to roundtrip times to the database, an acceptable solution
is to duplicate the needed information in the relationship documents. You trade the inconvenience
of maintaining multiple copies of the same data for the low access time to that data. Unless
you have extreme requirements however, you do not need to do this.

View raw message