AMRIT SARKAR commented on SOLR-9530:

Updated Patch: SOLR-9530.patch

To comply multiple threads executing Atomic URP don't make incoming doc 
inconsistent which will eventually end up in DUP, necessary changes are done as 

1. Earlier only conventional updates are allowed through this URP, *now atomic 
updates can be passed.*
2. If the incoming doc contains fields with atomic update and those particular 
fields *are not part* of Atomic URP definition, they will be sent as it as to 
next processor
3. If the incoming doc contains fields with atomic update and those particular 
fields are part of Atomic URP definition:
    a. if the atomic-op on field in incoming doc *matches* with atomic-op in 
processor definition, *pass as it is* to the next processor.
    b. if the atomic-op on field in incoming doc *doesn't matches* with 
atomic-op in processor definition, *throw SolrException (403 Forbidden)*.

In case of multiple threads try to update the incoming doc to atomic-type 
update doc, all the threads will end up forming same atomic-type update doc (as 
same set of operations will be performed by 'SET' field).

[~noble.paul] kindly verify if the above changes satisfies the parallel 
execution of this URP by multiple threads.

[~ichattopadhyaya] regarding including the updated current *version* of the doc 
in Atomic URP, DUP itself is performing the same on its end for every atomic 
update doc, including current *version* in the doc. If multiple threads 
executes the update chain (includes the Atomic URP), once it reaches the DUP, 
it performs exactly the same you have specified i.e all except the first one 
will fail with a version conflict and the client could retry that document. 
Kindly review and let me know if my understanding is correct and adding 
*version* info in Atomic URP will make any significant difference in this 

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