[
https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573481#comment-16573481
]
David Smiley commented on SOLR-12638:
-------------------------------------
Yeah something like that. This feature you propose bares a lot of resemblance
to "atomic updates" (not to be confused with _in-place_ updates – e.g. numeric
DV updates). That code is largely handled by AtomicUpdateDocumentMerger called
by DistributedUpdateProcessor. It seems to me this proposed feature would work
with that same code in some way. For example, after potentially doing an
atomic update (i.e. the document is partial), we then also potentially see if
it's a nested doc by checking for \_ROOT\_ as you said. A tricky part may be
considering the update log via RealtimeGetComponent (see
DistributedUpdateProcessor.getUpdatedDocument). That API allows fetch-by-ID,
and we can input the root document ID. Hopefully we should get back the whole
child hierarchy... we may need to enhance RTG to ensure it does so when
consulting the index (seems reasonable to me). That's where you might employ
the child doc transformer. I believe the children will be attached to root
docs in the updateLog, since they are "underneath"/attached in the
serialization of each parent document. Note that an atomic update of a child
document won't actually consider the update log since the update log is keyed
by parent/root ID, not the ID of the child document.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
