[
https://issues.apache.org/jira/browse/SOLR-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15869552#comment-15869552
]
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
follows:
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
regard.
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
