[[grandparents]] === Grandparents and Grandchildren
The parent-child relationship can extend across more than one generation--grandchildren can ((("parent-child relationship", "grandparents and grandchildren")))((("grandparents and grandchildren")))have grandparents--but it requires an extra step to ensure that documents from all generations are indexed on the same shard.
Let's change our previous example to make the country type a parent of the
branch type:
PUT /company { "mappings": { "country": {}, "branch": { "_parent": { "type": "country" <1> } }, "employee": { "_parent": { "type": "branch" <2> } } } }
<1> branch is a child of country.
<2> employee is a child of branch.
Countries and branches have a simple parent-child relationship, so we use the same process as we used in <>:
POST /company/country/_bulk { "index": { "_id": "uk" }} { "name": "UK" } { "index": { "_id": "france" }} { "name": "France" }
POST /company/branch/_bulk { "index": { "_id": "london", "parent": "uk" }} { "name": "London Westmintster" } { "index": { "_id": "liverpool", "parent": "uk" }} { "name": "Liverpool Central" } { "index": { "_id": "paris", "parent": "france" }} { "name": "Champs Élysées" }
The parent ID has ensured that each branch document is routed to the same
shard as its parent country document. However, look what would happen if we
were to use the same technique with the employee grandchildren:
PUT /company/employee/1?parent=london { "name": "Alice Smith", "dob": "1970-10-24", "hobby": "hiking" }
The shard routing of the employee document would be decided by the parent ID—london—but the london document was routed to a shard by its own
parent ID—uk. It is very likely that the grandchild would end up on
a different shard from its parent and grandparent, which would prevent the
same-shard parent-child mapping from functioning.
Instead, we need to add an extra routing parameter, set to the ID of the
grandparent, to ensure that all three generations are indexed on the same
shard. The indexing request should look like this:
PUT /company/employee/1?parent=london&routing=uk <1> { "name": "Alice Smith", "dob": "1970-10-24", "hobby": "hiking" }
<1> The routing value overrides the parent value.
The parent parameter is still used to link the employee document with its
parent, but the routing parameter ensures that it is stored on the same
shard as its parent and grandparent. The routing value needs to be provided
for all single-document requests.
Querying and aggregating across generations works, as long as you step through each generation. For instance, to find countries where employees enjoy hiking, we need to join countries with branches, and branches with employees: