You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "nick-boss-tech (via GitHub)" <gi...@apache.org> on 2026/10/09 20:31:38 UTC
[PR] SOLR-5065: ParseDoubleFieldUpdateProcessorFactory is unable to parse "+" in exponent [solr]
nick-boss-tech opened a new pull request, #5071:
URL: https://github.com/apache/solr/pull/5071
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)*
https://issues.apache.org/jira/browse/SOLR-5065
## What happens today
**Exponents with a plus sign or a lowercase marker are not parsed by the parse-double and parse-float processors.**
Forms such as `4.5E+10` (a plus sign) and `4.5e3` (a lowercase marker) do not parse. The shared helper runs `NumberFormat` on the whole value and checks that every character was used. When one was not, the value is left unchanged, and the processor logs that at debug level ([parsePossibleDouble](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/java/org/apache/solr/update/processor/ParseDoubleFieldUpdateProcessorFactory.java#L102-L116)).
## What this change does
**A trailing exponent is rewritten before `NumberFormat` runs, so both forms parse.**
- A plus sign after the exponent marker is removed, and a lowercase marker becomes uppercase. `4.5E+10` becomes `4.5E10`, and `4.5e-3` becomes `4.5E-3` ([helper](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/java/org/apache/solr/update/processor/ParseNumericFieldUpdateProcessorFactory.java#L49-L65)). The rewrite only touches a trailing exponent, so other values are not changed.
- The double and float processors both call the helper ([double](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/java/org/apache/solr/update/processor/ParseDoubleFieldUpdateProcessorFactory.java#L104), [float](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/java/org/apache/solr/update/processor/ParseFloatFieldUpdateProcessorFactory.java#L93)).
- The rewrite runs whatever `locale` is set.
- The schema suggester uses the same helper ([isFloatOrDouble](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/java/org/apache/solr/handler/designer/DefaultSchemaSuggester.java#L294-L300)). Samples with these forms now infer `pdouble`. This is an intended effect, and a test pins it.
## Proof
**The suggester pin test fails without this change and passes with it.**
- `ParsingFieldUpdateProcessorsTest` 44 of 44 pass with this change. The new tests are `testParseDoubleExponentForms` and `testParseFloatExponentForms` ([tests](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java#L642-L719)).
- `DefaultSchemaSuggesterTest` 2 of 2 pass ([class](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/test/org/apache/solr/handler/designer/DefaultSchemaSuggesterTest.java#L31-L49)). The pin test is [`testGuessFieldTypeExponentFormsInferDouble`](https://github.com/nick-boss-tech/solr/blob/ab894a996c8aa9825c4ac5af38536aec1ee865eb/solr/core/src/test/org/apache/solr/handler/designer/DefaultSchemaSuggesterTest.java#L33-L41). It fails on the unmodified base, 0cc328310f8f, and passes with this change.
- The module check is clean.
- Verified 2026-10-09 at this head.
## Limits
**Locale-aware parsing is not in this change. It stays open for the ticket.**
- The rewrite ignores `locale`, so a non-ROOT locale gets the same exponent rewrite as ROOT. A locale-aware parse would be a separate choice.
- No test runs an exponent form under a non-ROOT locale, or with spaces around the value.
- The reference guide does not describe the accepted exponent forms. This change makes no documentation change.
Changelog: `changelog/unreleased/SOLR-5065-parse-double-exponent-plus.yml`
### 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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] SOLR-5065: ParseDoubleFieldUpdateProcessorFactory is unable to parse "+" in exponent [solr]
Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on code in PR #5071:
URL: https://github.com/apache/solr/pull/5071#discussion_r4237417853
##########
solr/core/src/java/org/apache/solr/update/processor/ParseNumericFieldUpdateProcessorFactory.java:
##########
@@ -45,8 +46,24 @@ public abstract class ParseNumericFieldUpdateProcessorFactory
private static final String LOCALE_PARAM = "locale";
+ private static final Pattern EXPONENT_PLUS = Pattern.compile("([eE])\\+(\\d+)$");
+
+ private static final Pattern LOWERCASE_EXPONENT = Pattern.compile("(\\d)e([+-]?\\d+)$");
+
protected Locale locale = Locale.ROOT;
+ /**
+ * Normalizes a trailing exponent so {@link java.text.NumberFormat} can parse it, e.g. {@code
+ * 4.5E+10} becomes {@code 4.5E10} and {@code 4.5e-3} becomes {@code 4.5E-3}. NumberFormat accepts
+ * neither a plus sign in the exponent nor a lowercase exponent marker, but Java, JSON and the
+ * corresponding Solr field types accept both. Both rewrites are anchored to a trailing exponent,
+ * so a value without one is returned unchanged.
+ */
+ static String normalizeExponent(String value) {
Review Comment:
is there a math library we could be using to handle all variotions of string that are numbers? I guess I am wondering if this PR fixes tehse two specific examples, does that me we fixed em all? Or are there many other variations that people will stumble across that need mroe regexing? Seems like taking a string that represents a number and making it a true number isn't a werid thing to do in java? Maybe we get lucky and already depend on a lib that does this?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] SOLR-5065: ParseDoubleFieldUpdateProcessorFactory is unable to parse "+" in exponent [solr]
Posted by "nick-boss-tech (via GitHub)" <gi...@apache.org>.
nick-boss-tech commented on code in PR #5071:
URL: https://github.com/apache/solr/pull/5071#discussion_r4240214704
##########
solr/core/src/java/org/apache/solr/update/processor/ParseNumericFieldUpdateProcessorFactory.java:
##########
@@ -45,8 +46,24 @@ public abstract class ParseNumericFieldUpdateProcessorFactory
private static final String LOCALE_PARAM = "locale";
+ private static final Pattern EXPONENT_PLUS = Pattern.compile("([eE])\\+(\\d+)$");
+
+ private static final Pattern LOWERCASE_EXPONENT = Pattern.compile("(\\d)e([+-]?\\d+)$");
+
protected Locale locale = Locale.ROOT;
+ /**
+ * Normalizes a trailing exponent so {@link java.text.NumberFormat} can parse it, e.g. {@code
+ * 4.5E+10} becomes {@code 4.5E10} and {@code 4.5e-3} becomes {@code 4.5E-3}. NumberFormat accepts
+ * neither a plus sign in the exponent nor a lowercase exponent marker, but Java, JSON and the
+ * corresponding Solr field types accept both. Both rewrites are anchored to a trailing exponent,
+ * so a value without one is returned unchanged.
+ */
+ static String normalizeExponent(String value) {
Review Comment:
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)*
**No library Solr has does this job, and for exponent spellings the two fixes are the complete set.**
I checked the parsers on JDK 21: Double.parseDouble, BigDecimal, and NumberUtils from commons-lang3 3.20.0, which Solr core already depends on. None of the three accepts grouping separators or takes a locale. These factories parse with NumberFormat because it does both, in the configured locale. Its one gap is exponents: it rejects a plus sign (4.5E+10) and a lowercase marker (4.5e-3), forms that Java, JSON, and the Solr field types all accept.
The rewrite runs in the Double and Float factories and fixes exactly that gap: a lowercase e becomes E, and the plus sign in the exponent is removed. After it, every exponent spelling is accepted: E or e, with +, -, or no sign, with or without grouping. Other forms stay as they were. Hex floats and a trailing d suffix stay rejected, as before this change, and the rewrite touches only a trailing exponent, so a trailing space or a form like 5.e3 still fails. Those are not spellings JSON or the field types produce.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org