Alexandre Rafalovitch commented on SOLR-9530:

Ok, that makes sense. And if this URP is defined as a standalone item, it could 
be triggered as a pre-processor in a request parameter for the second call. 
This would simplify output formats for 3rd parties.


> 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
> 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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to