I read in the "breaking changes in 2.0":
"The mapping for the parent type can be added at the same time as the mapping for the child type, but cannot be added before the child type."
I understand this to mean "You can never add new child-types which have a parent that already exists (and is a parent of another already existing child-type)." Do I understand this correct?
Our application, which we started to develop some weeks ago, relies heavily on the idea of "core data" (parents) which have many child-types, created at start and added over time.
How can this still be made possible with 2.+?
Yes, a new child type can't point to an existing type as parent.
This has to do with the fact that with the new parent/child implementation both parent and child types store ids in a join field. If type becomes a parent after it has been created then parent documents may have been indexed that didn't store their id in the join field. For this reason this restriction exists.
This only applies for new indices created after the upgrade to ES 2.0. For migration purposes this restriction doesn't apply for indices created before the upgrade to ES 2.0. In fact on created on ES 1.x and before the old parent/child implementation is being used.
Thanks for clarifying, Martijn.
That said, I would hate to not take advantage of ES2.0
Now, we could have the relations completely on the side of the application, but maybe an idea on how to cleverly build such a flexible concept while using support of ES?
In your case I'd always add a child type when a adding a parent type (which initially doesn't have any real children docs, until you start using the child type). The overhead for this is minimal. (just storage, for the join field for the docs under the parent type).
Is there any plan to remove this limitation? I thought I had found a good solution with Parent/Child documents vs Nested documents, due to frequent updates/additions of child documents... Unfortunately, now in 2.x I can't simply add new child types, which is definitely a requirement for my application.... Thoughts?
As indicated in October, we have since moved all handling of flexible relations (1-1, 1-x, x-x) to our application layer. It works well and is fast, fast enough for our usage pattern. That said, it still feels semi optimal and I would still love to see a way of handling this directly in the underlying DB-engine. Once our product is finished and tested I plan to write up a description of the project and how we handled things for the community.
Thanks for the reply. Although the question was more for Martijn, I appreciate your take on the matter and agree with you that it feels "semi optimal". I really look forward to your write up on how you addressed this limitation applications side. Cheers!
Yes, adding child mapping that points to an already existing parent mapping is not allowed any more.
In that case you should take this into account when adding the parent mapping, so when creating the index add the parent mapping and any child mappings you end up needing in the future.
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.