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: [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]
