[
https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15038858#comment-15038858
]
Hoss Man commented on SOLR-5211:
--------------------------------
I thought i had made this straw many suggestion in some jira at some point, but
I can't find it now....
I think a robust solution to dealing with multi-level nested documents and
deletions (as i understand the rules of block joins) would be to extend the
\_root\_ field concept to an \_ancestors\_ concept -- the \_ancestors\_ field
would be multivalued and contain the uniqueKey of every "ancestor" document, as
well as the uniqueKey of the current document.
ie: if "id:parent" has 2 children then "id:child1" has both "parent" and
"child1" in it's \_ancestors\_ field. likewise if you have a deep hierarchy of
"A(B(C,D),E(F(G,H),I(J)))" then the \_ancestors\_ field for "H" would contain
"A E H"
This then means that any deleteById or deleteByQuery that involves the
uniqueKey field can/should be re-rewitten to be a delete ased on that term
value against the \_ancestors\_, so that all decendents of the uniqueKey
specified are deleted.
(not sure how to do this in a back compat way, but an idea i wanted to throw
out there)
> updating parent as childless makes old children orphans
> -------------------------------------------------------
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
> Issue Type: Sub-task
> Components: update
> Affects Versions: 4.5, Trunk
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> if I have parent with children in the index, I can send update omitting
> children. as a result old children become orphaned.
> I suppose separate \_root_ fields makes much trouble. I propose to extend
> notion of uniqueKey, and let it spans across blocks that makes updates
> unambiguous.
> WDYT? Do you like to see a test proves this issue?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
