nick-boss-tech opened a new pull request, #5096: URL: https://github.com/apache/solr/pull/5096
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-12705 ## What happens today **A field mutating update processor does not touch the value inside an atomic update.** For example, ParseDateFieldUpdateProcessorFactory skips an update such as `{"set": "2010-11-12T13:14:15.168Z"}`. The value is a map, not a string, so the processor leaves the field unchanged. The date parser never runs on the operand ([ParseDateFieldUpdateProcessorFactory.java#L113-L120](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java#L113-L120)). ## What this change does **The set, add, add-distinct and remove operations of an atomic update now go through the mutator. Other operations are left as they are.** - If a field's only value is an operation map, `processAdd` runs `mutate` on the operand of each set, add, add-distinct and remove operation ([FieldMutatingUpdateProcessor.java#L109-L111](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L109-L111), [#L151-L182](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L151-L182)). Operations such as `inc` keep their operands. An update with only those operations is handled as before. - This is wider than the ticket's narrowest reading. It applies to every subclass of `FieldMutatingUpdateProcessor`, not only the date parser. - A subclass can opt out by overriding the new protected method `mutateAtomicOperands()`, which returns true by default ([L74-L86](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L74-L86)). A new public overload, `mutator(selector, next, fun, applyToAtomicOperands)`, sets the same switch ([L358-L374](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L358-L374)). - `CountFieldValuesUpdateProcessorFactory` opts out ([L67-L75](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/CountFieldValuesUpdateProcessorFactory.java#L67-L75)). Counted fields follow the rule in [SOLR-7504](https://issues.apache.org/jira/browse/SOLR-7504), which lands first. ## Proof **The focused suites pass at this head, and a combined run with SOLR-7504 passes too.** - `FieldMutatingUpdateProcessorTest`: 25 tests, 0 failures. Verified 2026-10-09 at `aa56b7b1be4`. [`testAtomicOperandsOptOut`](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/test/org/apache/solr/update/processor/FieldMutatingUpdateProcessorTest.java#L810-L855) checks the opt-out. An operation map passes through the mutator untouched, and plain values are still mutated. Without the opt-out, the same mutator changes the operand ([L853-L854](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/test/org/apache/solr/update/processor/FieldMutatingUpdateProcessorTest.java#L853-L854)). The test does not assert counted-field outcomes. - `ParsingFieldUpdateProcessorsTest`: 43 tests, 0 failures, same date and head. [`testParseDateInAtomicUpdateOperations`](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java#L68-L99) checks that the `set` and `add` operands are parsed as dates, that `inc` is untouched, and that a field the selector skips keeps its string. - A combined run with SOLR-7504 at `22b77196e662` passed on 2026-10-09: both suites green, 30 of 30 and 43 of 43. ## Limits **A few cases are untested, one behavior is missing from the changelog, and two changes land first.** - The date-parse test does not cover `add-distinct` or `remove`. No test checks the case where the processor returns nothing for an operand, so that operation is dropped. - A field with several operation maps in one update is passed to `mutate` unchanged. This limit was already there. It is not a regression. - If the mutator returns nothing for every value operation in an atomic update, and no other operation remains, `processAdd` removes the whole field from the update ([L118-L120](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L118-L120), [L176-L177](https://github.com/nick-boss-tech/solr/blob/aa56b7b1be4c5491723c58f296e20c906d7b7334/solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessor.java#L176-L177)). The changelog does not mention this. - Landing order. [SOLR-7504](https://issues.apache.org/jira/browse/SOLR-7504) and [SOLR-16655](https://issues.apache.org/jira/browse/SOLR-16655) land before this change. The combined run above is the reason SOLR-7504 goes first. SOLR-16655 is confined to the child-document descent in `mutateDocument`. This change is the broader atomic operands rework in the same file, and it rebases onto SOLR-16655. The two conflict in `FieldMutatingUpdateProcessor.java`. Changelog: `changelog/unreleased/SOLR-12705-field-mutating-atomic-updates.yml` (type: fixed). ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
