Managing IDs in the new join field in place of Parent-Child

Elastic Stack Elasticsearch
1

Hello,

With ES 5.6 and ES 6.x, the _parent mapping feature and _type have been deprecated and soon to be removed. Earlier, we could write parent documents separately, and child documents separately and not have conflicts on their IDs as they'll be in two different types. By now that types have been removed, am I correct in assuming that there'll be a conflict of ID/overwrite when parent and child documents have the same ID?

In such a case, is there any provision or setting to prevent this from happening? Or is it upto the client to ensure sending non-conflicting IDs in such cases?

Example

Assume that we store stackoverflow data on an index. So the appropriate minimal schema would be:

Question:

  • Title
  • Content

Answers:

  • Content

In JSON, this would look something like:

{
    "mappings":{
        "question": {
            // Title, content mappings
        },
        "answer": {
            "_parent": {
                "type": "question"
            }
        }
     }
}

So this allowed me to write separate non-conflicting docs to each type:

curl -XPUT localhost:9200/so_index/question/1?routing=1 -d '{"title": "..", "content": ".."}'
curl -XPUT localhost:9200/so_index/answer/1?routing=1 -d '{"content": ".."}'

So with the new implementation, not only I'm forced to map the "child type" to a parent (which will be removed in ES 7 of course), I've to also resolve _id 1 of parent to not conflict with _id 1 of child. So when writing a child, like shown below, it would actually overwrite the parent if the _id is same.

// Writing PARENT
curl -XPUT localhost:9200/so_index/question/1?routing=1 -d '{"title": "..", "content": "..", "join_type": { "name": "question" }}'

// Writing CHILD.
// Passing parent "type" when writing child
// Also this would overwrite the parent actually
curl -XPUT localhost:9200/so_index/question/1?routing=1 -d '{"content": "..", "join_type": { "name": "answer", "parent": 1 }}'
2

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.