[
https://issues.apache.org/jira/browse/SOLR-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872336#comment-17872336
]
Tim Owen commented on SOLR-17397:
---------------------------------
We've only recently started using child docs (having been heavy Solr users for
13 years now) so it did feel a little bit 2nd class in some areas. To be fair,
this particular update processor was one we originally submitted so it's my
fault it didn't support child docs!
I will take a look at others, I suspect anything using RTG to look up the doc
may need checking to see how it would work with a child doc.
The other issue I am about to raise in a ticket (because we needed to fix it in
our internal build too) is that atomic updates now support nested atomic
updates, since SOLR-15213 and those require the child doc to exist. My patch
for that in AtomicUpdateDocumentMerger is maybe less acceptable, as it relies
on sharing the same request parameter as this update processor uses. Overall,
the behaviour we want for atomic updates is to be like Database SQL, where an
update will quietly do nothing for non-existent documents.
> Skip atomic updates for non-existent child documents
> ----------------------------------------------------
>
> Key: SOLR-17397
> URL: https://issues.apache.org/jira/browse/SOLR-17397
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
> Reporter: Tim Owen
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have an update processor that allows skipping updates for non-existent
> documents, {{SkipExistingDocumentsUpdateProcessor}} but this does not
> currently handle atomic updates to child documents. So the update is passed
> through and then fails because {{AtomicUpdateDocumentMerger}} throws an
> exception if it cannot find the child document (leading to a 500 response
> from Solr)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
