[
https://issues.apache.org/jira/browse/SOLR-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984985#comment-15984985
]
Erick Erickson commented on SOLR-9530:
--------------------------------------
1 ms is much too short. I'd just issue the commit() when done sending docs then
the wait.
The question is did your change work? As in prevent errors? If so let's try the
loop above as a stop-gap.
> Add an Atomic Update Processor
> -------------------------------
>
> Key: SOLR-9530
> URL: https://issues.apache.org/jira/browse/SOLR-9530
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
> Attachments: SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch,
> SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch,
> SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch
>
>
> I'd like to explore the idea of adding a new update processor to help ingest
> partial updates.
> Example use-case - There are two datasets with a common id field. How can I
> merge both of them at index time?
> Proposed Solution:
> {code}
> <updateRequestProcessorChain name="atomic">
> <processor class="solr.processor.AtomicUpdateProcessorFactory">
> <str name="my_new_field">add</str>
> </processor>
> <processor class="solr.LogUpdateProcessorFactory" />
> <processor class="solr.RunUpdateProcessorFactory" />
> </updateRequestProcessorChain>
> {code}
> So the first JSON dump could be ingested against
> {{http://localhost:8983/solr/gettingstarted/update/json}}
> And then the second JSON could be ingested against
> {{http://localhost:8983/solr/gettingstarted/update/json?processor=atomic}}
> The Atomic Update Processor could support all the atomic update operations
> currently supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
