[
https://issues.apache.org/jira/browse/SOLR-14868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196560#comment-17196560
]
Chris M. Hostetter commented on SOLR-14868:
-------------------------------------------
I created this issue mainly as a starting point for disucssion in case it
spawned any idea from the folks with a good understanding of the nested
documents logic as to how we could go about doing this in a more efficient way.
Practically speaking, i'm not really sure if/how there is a good way to go
about implementing this improvement to the current "remove" atomic update
operation, given where/how the atomic update logic is handled in the update
logic flow.
An alternative approach might be to revisit the decision to prevent "delete by
id" from being usable on "child" documents. I'm not even sure where/how this
happens, but in theory whatever bit of code checks the ID value to see if it's
_not_ a "root" id could -- instead of ignoring child ids -- pull the "root"
"nest_path" of the specified ID out of DocValues and use them to build a
"delete by query" for the both specified (child) doc and any descendants it has.
> nested document 'remove' operation should "delete in place"
> -----------------------------------------------------------
>
> Key: SOLR-14868
> URL: https://issues.apache.org/jira/browse/SOLR-14868
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> Currently, if you use the "remove" atomic update operation for nested
> documents, it completely re-indexes the "root" document and all remaining
> child documents (after logically removing the specified child and i'ts
> descendants)
> ideally, unless this operation is combined with other atomic update
> operations, "remove" should be done "in place" -- just using the IndexWriter
> to mark the specified child document (and it's descendants) as deleted.
> (The full Re-Indexing of the 'root' level document can be very slow for large
> deeply nested documents)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
