[
https://issues.apache.org/jira/browse/SOLR-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718535#comment-13718535
]
Jack Krupansky commented on SOLR-5065:
--------------------------------------
I'll suggest one simple hack:
1. Attempt to parse using NumberFormat, to get full locale support.
2. On failure, attempt to parse using Java number format. No locale support,
but better than what happens now.
Another hack option:
1. Attempt to parse using NumberFormat, to get full locale support.
2. On failed parse, check for "[eE]+" in input value. If found, remove the plus
and attempt parse with NumberFormat again.
That would support both Java/JSON/Solr numbers and locale as well (as long as
the locale used e/E for exponent.) I think the locale-independent Java/JSON
exponent patten check/fix should be fine, since it is really only trying to add
Java/JSON/Solr number support, which is not locale-specific.
> 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
