[
https://issues.apache.org/jira/browse/SOLR-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718025#comment-13718025
]
Steve Rowe commented on SOLR-5065:
----------------------------------
bq. would it be worthwhile to add a "java-mode" init param
I guess by "java-mode" you mean "supporting the same set of numeric expressions
as the Java programming language"? Seems like a weirdly narrow (though
accurate) label. It makes me think: will most consumers of this functionality
care about conformity with the Java language spec? (I kinda doubt it.)
Maybe the init param could be named "provider" or "parser", with supported
values "Number.valueOf" and "NumberFormat"? That would allow for future
extensibility, perhaps to include the ICU implementation (which looks to me
like a more evolved version of Java's NumberFormat stuff).
bq. would it also make sense to change the default behavior of {{<processor
class="solr.ParseDoubleFieldUpdateProcessorFactory" />}} from assuming
{{locale="ROOT"}} to {{java-mode="true"}} ?
One way to think about this: is it more likely that users will have documents
with numbers that have plus signs in the exponent than it is that they will
have documents with numbers that have grouping separators, e.g. "10,123"?
All that said, I still think the plus-sign-stripping regex would fix the
immediate problem without making the implementations more complicated.
> ParseDoubleFieldUpdateProcessorFactory is unable to parse "+" in exponent
> -------------------------------------------------------------------------
>
> Key: SOLR-5065
> URL: https://issues.apache.org/jira/browse/SOLR-5065
> Project: Solr
> Issue Type: Bug
> Components: update
> Affects Versions: 4.4
> Reporter: Jack Krupansky
>
> The ParseDoubleFieldUpdateProcessorFactory is unable to parse the full syntax
> of Java/JSON scientific notation. Parse fails for "4.5E+10", but does succeed
> for "4.5E10" and "4.5E-10".
> Using the schema and config from example-schemaless, I added this data:
> {code}
> curl "http://localhost:8983/solr/update?commit=true"; \
> -H 'Content-type:application/json' -d '
> [{"id": "doc-1",
> "a1": "Hello World",
> "a2": 123,
> "a3": 123.0,
> "a4": 1.23,
> "a5": 4.5E+10,
> "a6": "123",
> "a7": true,
> "a8": false,
> "a9": "true",
> "a10": "2013-07-22",
> "a11": 4.5E10,
> "a12": 4.5E-10,
> "a13": "4.5E+10",
> "a14": "4.5E10",
> "a15": "4.5E-10"}]'
> {code}
> A query returns:
> {code}
> <doc>
> <str name="id">doc-1</str>
> <arr name="a1">
> <str>Hello World</str>
> </arr>
> <arr name="a2">
> <long>123</long>
> </arr>
> <arr name="a3">
> <double>123.0</double>
> </arr>
> <arr name="a4">
> <double>1.23</double>
> </arr>
> <arr name="a5">
> <double>4.5E10</double>
> </arr>
> <arr name="a6">
> <long>123</long>
> </arr>
> <arr name="a7">
> <bool>true</bool>
> </arr>
> <arr name="a8">
> <bool>false</bool>
> </arr>
> <arr name="a9">
> <bool>true</bool>
> </arr>
> <arr name="a10">
> <date>2013-07-22T00:00:00Z</date>
> </arr>
> <arr name="a11">
> <double>4.5E10</double>
> </arr>
> <arr name="a12">
> <double>4.5E-10</double>
> </arr>
> <arr name="a13">
> <str>4.5E+10</str>
> </arr>
> <arr name="a14">
> <double>4.5E10</double>
> </arr>
> <arr name="a15">
> <double>4.5E-10</double>
> </arr>
> <long name="_version_">1441308941516537856</long></doc>
> {code}
> The input value of a13 was the same as a5, but was treated as a string,
> rather than parsed as a double. So, JSON/Java was able to parse "4.5E+10",
> but this update processor was not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
