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...