I'm looking at starting to use ElasticSearch in a new project. I'm
just starting, but but looks great so far.
I ran across the new parent/child relationship support. In my use-
case, we will keep appending stuff to documents, and the stuff we
append with be considered part of the document. Since parent/child is
so new, I don't see much on it yet.
Imagine a blog with comments, where the comments are considered part
of the document. So, as each comment is added, could I add it as a
child document (without having to re-index the whole main document and
existing comments)? Is this a good solution? Will it cause any
problems/while I lose any functionality?
Also, will it work with more_like_this queries?
If not, is there a better way to append stuff to documents without re-
sending the whole document?
Currently, the main use case for parent child (with the current set of
features) is filtering based on highly dynamic data that is not required to
be fetched / highlighted with the parent doc itself.
As to solving the blog and comment same, it really depends on how you
envision your search interface to look like. Will it return just posts, just
comments, both? You can always store them as two different types and just
execute the query, you will get back both posts and comments. The comment
can have (using parent mapping for example, but not required) a reverse id
of the blog post.
On Mon, Jan 3, 2011 at 9:28 PM, Dan Gould dlg@dangould.com wrote:
Hi,
I'm looking at starting to use Elasticsearch in a new project. I'm
just starting, but but looks great so far.
I ran across the new parent/child relationship support. In my use-
case, we will keep appending stuff to documents, and the stuff we
append with be considered part of the document. Since parent/child is
so new, I don't see much on it yet.
Imagine a blog with comments, where the comments are considered part
of the document. So, as each comment is added, could I add it as a
child document (without having to re-index the whole main document and
existing comments)? Is this a good solution? Will it cause any
problems/while I lose any functionality?
Also, will it work with more_like_this queries?
If not, is there a better way to append stuff to documents without re-
sending the whole document?
Thank you Shay. It sounds like Parent/Chlld would be a win, but
doesn't do everything I'll need.
(What would be amazing for my use-case would be if the child nodes
could be treated as fully part of the document. Or if there was an
append function for documents.)
Currently, the main use case for parent child (with the current set of
features) is filtering based on highly dynamic data that is not required to
be fetched / highlighted with the parent doc itself.
As to solving the blog and comment same, it really depends on how you
envision your search interface to look like. Will it return just posts, just
comments, both? You can always store them as two different types and just
execute the query, you will get back both posts and comments. The comment
can have (using parent mapping for example, but not required) a reverse id
of the blog post.
I'm looking at starting to use Elasticsearch in a new project. I'm
just starting, but but looks great so far.
I ran across the new parent/child relationship support. In my use-
case, we will keep appending stuff to documents, and the stuff we
append with be considered part of the document. Since parent/child is
so new, I don't see much on it yet.
Imagine a blog with comments, where the comments are considered part
of the document. So, as each comment is added, could I add it as a
child document (without having to re-index the whole main document and
existing comments)? Is this a good solution? Will it cause any
problems/while I lose any functionality?
Also, will it work with more_like_this queries?
If not, is there a better way to append stuff to documents without re-
sending the whole document?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.