There are some alternatives for mapping the code index.
Parent joins
We can add parent joins and use has_parent/ has_child queries. These would allow us to find codes from queries about other codes. It looks like the parent_id query is equivalent to a term search on "broader" but there may be indexing benefits.
Nesting
We could nest the codes in a single codelist document.
This might be useful for the tree view (as it's already arranged!) but might need some way for us to walk the tree rather than extracting it all at once. Some docs to explore: retrieve inner hits and retrieve selected fields.
It might be tricky to search all codes (at any level) by label from the nested tree. We could always retain the code index fortext search and add a codelist index for the tree view.
There are some alternatives for mapping the code index.
Parent joins
We can add parent joins and use
has_parent
/has_child
queries. These would allow us to find codes from queries about other codes. It looks like theparent_id
query is equivalent to a term search on"broader"
but there may be indexing benefits.Nesting
We could nest the codes in a single codelist document.
This might be useful for the tree view (as it's already arranged!) but might need some way for us to walk the tree rather than extracting it all at once. Some docs to explore: retrieve inner hits and retrieve selected fields.
It might be tricky to search all codes (at any level) by label from the nested tree. We could always retain the
code
index fortext search and add acodelist
index for the tree view.