[
https://issues.apache.org/jira/browse/SOLR-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718511#comment-13718511
]
Hoss Man commented on SOLR-5065:
--------------------------------
bq. 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's a terrible name i agree -- but i was thinking of it more from the
standpoint of "how the values will be parsed by the underlying Solr FieldType
if this update processor wasn't used"
bq. 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"?
But in the later case, they should have to think about what "locale" they want
to ues to deal with grouping separators, and make a conscious choice .... for
the "default" behavior, using hte exact same parsing rules as the TrieField
would if you didn't have the processor, or as what you'd get if you added the
number via SolrJ -- using either JavaBin or xml -- seems like a better default
(evidently) then Locale.ROOT.
bq. And my real bottom line is that if a double syntax is acceptable by Solr
itself for a double/trie double field, it should be acceptable by this
processor.
+1 ... with the obvious caveat if the user explicitly configures a locale, we
should use the parser of their choosen locale and the acceptable syntax
obviously changes
> 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
