[
https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574834#comment-16574834
]
David Smiley commented on SOLR-12638:
-------------------------------------
I could have been more clear. The update log is keyed by the outer most
document of any nesting that may exist, and thus any nested docs can't be
looked up by their ID. So if a complete nested document were to be in the
update log, and then subsequently one of those nested documents stand-alone,
then the atomic update processing of that standalone document will not "see"
that it was also present underneath a parent recently. It would *see* if per
chance there were multiple atomic updates to just this child document (since
they are keyed in the update log by their ID), but not any nested cases which
is keyed only by the top/root/parent ID.
I think this just needs to be a documented limitation/gotcha to be aware of; I
don't think it's something that could or should be solved.
> Provide a simple API to update block (update child documents)
> -------------------------------------------------------------
>
> Key: SOLR-12638
> URL: https://issues.apache.org/jira/browse/SOLR-12638
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: mosh
> Priority: Major
>
> I have been toying with the thought of using this transformer in conjunction
> with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely
> re-index the entire nested structure. This is just a thought, I am still
> thinking about implementation details. Hopefully I will be able to post a
> more concrete proposal soon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
