# Indexing of couchdb views? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 27, 2011, 8:32pm UTC](https://discuss.elastic.co/t/indexing-of-couchdb-views/3834 "2011-01-27T20:32:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![sdistefano](https://avatars.discourse-cdn.com/v4/letter/s/50afbb/32.png) [@sdistefano](https://discuss.elastic.co/u/sdistefano)\ **Post date:** [January 27, 2011, 8:32pm UTC](https://discuss.elastic.co/t/indexing-of-couchdb-views/3834/1 "2011-01-27T20:32:17Z")
Imagine that I have a database of recipes where a database of recipes where users can post comments, images and perhaps even comments on the images. I would like ES to be able to search on comments, but also to return the parent object (the recipe), as the result, as the comment on itself has little value. In short, I would like ES to return the recipe because one of the comments on it has matched the query. Therefore at the searchable index level, I would want a really long json document where comments / images and etc would be lists of dicts... so far so good. The problem is that because of the size of the data, I would probably have to split this into several documents of different types, that can be joined. Otherwise updates to couchdb would lock and my application would be constantly retrieving these massive objects, loading them into memory, appending to them and storing them back .... over while a loop!, so that conflicts can be handled. Not ideal. However, I could make a couchdb view that generates this sort of long index efficiently out of several JOINed objects. In this case it would be great if I could get ES to keep this index friendly view, rather than duplicating couchdb's format. And it would be fantastic if I could get that index automatically updated whenever the db (and thus the view) gets modified. Is something like this possible? Or do you think I am looking at this from the wrong point of view? I am rather new to nosql, so the latter is likely... ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 29, 2011, 1:52pm UTC](https://discuss.elastic.co/t/indexing-of-couchdb-views/3834/2 "2011-01-29T13:52:47Z")
I am not sure I understand. You should be able to use \_change API on a couchdb view, no? On Thursday, January 27, 2011 at 10:32 PM, sdistefano wrote: > Imagine that I have a database of recipes where a database of recipes > where users can post comments, images and perhaps even comments on the > images. > I would like ES to be able to search on comments, but also to return > the parent object (the recipe), as the result, as the comment on > itself has little value. In short, I would like ES to return the > recipe because one of the comments on it has matched the query. > Therefore at the searchable index level, I would want a really long > json document where comments / images and etc would be lists of > dicts... so far so good. > > The problem is that because of the size of the data, I would probably > have to split this into several documents of different types, that can > be joined. Otherwise updates to couchdb would lock and my application > would be constantly retrieving these massive objects, loading them > into memory, appending to them and storing them back .... over while a > loop!, so that conflicts can be handled. Not ideal. > However, I could make a couchdb view that generates this sort of long > index efficiently out of several JOINed objects. In this case it would > be great if I could get ES to keep this index friendly view, rather > than duplicating couchdb's format. And it would be fantastic if I > could get that index automatically updated whenever the db (and thus > the view) gets modified. > > Is something like this possible? Or do you think I am looking at this > from the wrong point of view? I am rather new to nosql, so the latter > is likely... ---
**Author:** ![Mahendra\_M](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mahendra_m/32/3128_2.png) [@Mahendra\_M](https://discuss.elastic.co/u/Mahendra_M)\ **Post date:** [January 31, 2011, 6:18am UTC](https://discuss.elastic.co/t/indexing-of-couchdb-views/3834/3 "2011-01-31T06:18:32Z")
Hi, I guess you are looking at from a different angle. The "recommended" approach for doing this in CouchDB would be - Have a main document (say 'type' = 'recipe') - Have each comment as a separate doc { 'type' : 'comment', 'recipe' : 'recipe\_doc\_id', '...' : '....', '...' : '....' } - Index the main doc and each of the comments in ES. The ES CouchDB river will take care of this automatically. - While searching for a comment in ES, you can use your 'recipe' doc\_id for a reference to your main recipe doc. Delving into some CouchDB stuff here. (You can get more details on how to use CouchDB for storing and retrieving comments from various CouchDB docs) Your view for listing a recipe and it's comments can be like this. if ( doc.type == 'comment' ) { emit( [doc.recipe, doc.date], [doc.title, doc.author] ); } With this, for a given recipe, you can load all the comments for a particular recipe by date and then display them in a paginated manner. Alter your view to suit your taste. PS: - CouchDB views are not indexed in ES. Only the docs are. - Sorry for the top post, but it looked better. Regards, Mahendra [http://twitter.com/mahendra](http://twitter.com/mahendra) On Fri, Jan 28, 2011 at 2:02 AM, sdistefano [sdistefano@gmail.com](mailto:sdistefano@gmail.com) wrote: > Imagine that I have a database of recipes where a database of recipes > where users can post comments, images and perhaps even comments on the > images. > I would like ES to be able to search on comments, but also to return > the parent object (the recipe), as the result, as the comment on > itself has little value. In short, I would like ES to return the > recipe because one of the comments on it has matched the query. > Therefore at the searchable index level, I would want a really long > json document where comments / images and etc would be lists of > dicts... so far so good. > > The problem is that because of the size of the data, I would probably > have to split this into several documents of different types, that can > be joined. Otherwise updates to couchdb would lock and my application > would be constantly retrieving these massive objects, loading them > into memory, appending to them and storing them back .... over while a > loop!, so that conflicts can be handled. Not ideal. > However, I could make a couchdb view that generates this sort of long > index efficiently out of several JOINed objects. In this case it would > be great if I could get ES to keep this index friendly view, rather > than duplicating couchdb's format. And it would be fantastic if I > could get that index automatically updated whenever the db (and thus > the view) gets modified. > > Is something like this possible? Or do you think I am looking at this > from the wrong point of view? I am rather new to nosql, so the latter > is likely... ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:13am UTC](https://discuss.elastic.co/t/indexing-of-couchdb-views/3834/4 "2017-07-06T04:13:06Z")