# Life without mapping types (6.0) **URL:** \ **Category:** Elasticsearch\ **Created:** [December 1, 2017, 12:43am UTC](https://discuss.elastic.co/t/life-without-mapping-types-6-0/109858 "2017-12-01T00:43:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Malik\_Rumi](https://avatars.discourse-cdn.com/v4/letter/m/5f9b8f/32.png) [@Malik\_Rumi](https://discuss.elastic.co/u/Malik_Rumi)\ **Post date:** [December 1, 2017, 12:43am UTC](https://discuss.elastic.co/t/life-without-mapping-types-6-0/109858/1 "2017-12-01T00:43:46Z")
I am trying to wrap my brain around the removal of mapping types in 6.0. [Removal of mapping types | Elasticsearch Guide [8.11] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html) 1. It seems that join and parent-child are almost completely analogous to the one to many concept in a relational database. However, in the example in the docs, [Join field type | Elasticsearch Guide [8.11] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html#_searching_with_parent_join), the child questions are not sorted with, or under, their parent questions, which I would think would be the default, and most common, use case. - Can it be done that way, despite this example? - Would, or could, the parent show up as a facet in a search for child, and vice-versa? - I've seen something like this done with breadcrumbs, but does elasticsearch leave all that to the backend script (python, java, php, etc)? - - A search for 'breadcrumbs' came up empty in the es docs. I found this example: [Has parent query | Elasticsearch Guide [8.11] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html#_sorting_2) but it does not answer the question of simply gathering all children with, or under, the parent. 1. Since both questions in the example have the same name, and differ only by id, that means you have to know the id. I'm using uuids, which are kind of hard to memorize, so searching with a filter is out. Is the workaround to give them different names, or is this 'same name' example an inherent part of this new (non) schema? 2. Conceptually, I would think 'my\_join\_field' is the one that ties a parent to its children, but instead it seems to tie documents to their siblings. I find that semantically confusing and not a user friendly choice, which is not remedied by the "my\_join\_field#question" syntax. That's obviously a comment and not a question, so I'll ask where I can give my user feedback to someone who not only cares but is in a position to do something about it? 3. Where does all of this leave a many to many relation? My search for 'manytomany' and 'many to many' also came up empty. 4. I am using the python dsl client, which makes it easy to wrap my existing models into DocTypes. Is that no longer possible, or will require a major refactor on my part? - - And if there is going to be a rewrite of the client, when will that happen? 1. Should all of these questions have been separate posts? 2. Similar prior questions: > [@Change the mapping from parent child to nested](https://discuss.elastic.co/t/change-the-mapping-from-parent-child-to-nested/89096): > > Hello, Currently, I have an index which holds 3 types of documents as described below. Document\_type1 (parent) Document\_type2 (child1 of parent) Document\_type3 (child2 of parent) Requirement: Change the parent child relationship to nested document structure. I would like to create a new index with the nested mappings and migrate the data from old\_index to new\_index (which has nested mapping) Is this possible ? If, yes what is the better approach. I looked at elastic reindex feature. Plea… _Closed with no answer_ > [@Three-level parent/child-mapping: Query the second level via its childs](https://discuss.elastic.co/t/three-level-parent-child-mapping-query-the-second-level-via-its-childs/7184): > > Hi! I'm trying to build an index schema with three levels, lets call them a, b and c, which are joined via parent-child-relations. The 'a' type is parent of the 'b' type, which again is parent of the 'c' type. Querying the top level, the 'a' type, via its 'b' children works without issues. However, when I try to query the middle 'b' level via its 'c' children, i.e. query /myindex/b/ with a has\_child() query for type 'c' with some query that matches one of the 'c' documents in my index, I … _3 level parent child no longer recommended._ [Join field type | Elasticsearch Guide [8.11] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html#_multiple_levels_of_parent_join) > [@Printing all children recursively while modeling parent-child mapping](https://discuss.elastic.co/t/printing-all-children-recursively-while-modeling-parent-child-mapping/15446): > > I am just getting started with elastic search , and one of our use cases we are trying to model our data which is very hirerchical in nature as a parent child. Was wondering if i have a document, could print all its children or the parent hirerchy recursively . Is this even possible? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscrib…](mailto:elasticsearch+unsubscribe@googlegroups.com) _Closed with no answer_ > [@Elasticsearch 6.0 and joining queries](https://discuss.elastic.co/t/elasticsearch-6-0-and-joining-queries/109353): > > Hello, I trying create relation parent-child as in docs ([https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html)) but when i querying: { "query": { "parent\_id": { "type": "answer", "id": "1" } }, "aggs": { "parents": { "terms": { "field": "my\_join\_field#question", "size": 10 } } }, "script\_fields": { "parent": { "script": { "source": "doc['my\_join\_field#question']" } } }… _3 days old as of this moment, but no answer yet._ ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [December 1, 2017, 6:33pm UTC](https://discuss.elastic.co/t/life-without-mapping-types-6-0/109858/2 "2017-12-01T18:33:00Z")
I tried to give some thoughts in the other post you sent about this: > [@Understand and using relationships without mapping types (6.0)](https://discuss.elastic.co/t/understand-and-using-relationships-without-mapping-types-6-0/109863): > > RE: Removal of mapping types [https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html) It looks like the proposed solution is to use a "common key" - my term. Such a common key can tie a user to a tweet, as in the example, but let's get serious, and talk about more complex, and I suspect, more common, and realistic use cases, shall we? Let's say I have a FACTORY, and I make PRODUCT. I have a supply chain of numerous different VENDORS, who sell me various PARTS, ING… ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 29, 2017, 6:33pm UTC](https://discuss.elastic.co/t/life-without-mapping-types-6-0/109858/3 "2017-12-29T18:33:16Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.