[
https://issues.apache.org/jira/browse/SOLR-12298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473401#comment-16473401
]
mosh commented on SOLR-12298:
-----------------------------
[~arafalov]
{quote}Perhaps somebody who has a recent ES installation can do this quick test
on what happens now, but - regardless - I think those original lessons may
still be something to consider as we are planning Solr changes.
{quote}
according to ES
[docs|https://www.elastic.co/blog/managing-relations-inside-elasticsearch]
there are three ways to index relations between docs.
It seems like the most flexible one is the parent-child, since it allows faster
updates, with a slightly slower read performance, because the documents are not
indexed in the same Lucene block, although they are indexed in the same shard.
> Index Full nested document Hierarchy For Queries (umbrella issue)
> -----------------------------------------------------------------
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: mosh
> Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing
> the original document hierarchy.
> Currently the client has to index the child document's full path and level
> to manually reconstruct the original document structure, since the children
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the
> required fields while providing a document transformer to rebuild the
> original document's hierarchy.
>
> This issue is an umbrella issue for the particular tasks that will make it
> all happen – either subtasks or issue linking.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
