[
https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744145#comment-16744145
]
Yosef Brown commented on SOLR-5211:
-----------------------------------
[~dsmiley]
bq. .... a delete-by-id would also only delete a root document ... my take-away
message to this is that we don't need to think of the delete-by-id limitation
of root documents as a problem. It's unusual to want to do otherwise (and
error-prone if you leave grandchildren orphaned), and it's possible to do this
via delete-by-query.
I'm unclear on your meaning. I would think the default behavior when deleting
a parent (regardless of by id or by query) should also delete its children, to
avoid ending up with orphans. Something like, deleting the block's root
deletes the whole block. This is similar to the current functionality that
overwrites (or rewrites) the whole block, including any children documents,
when updating a document.
> 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, 6.0
> Reporter: Mikhail Khludnev
> Assignee: David Smiley
> Priority: Blocker
> Fix For: 8.0
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch,
> SOLR-5211.patch, SOLR-5211.patch
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
