[
https://issues.apache.org/jira/browse/SOLR-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622650#action_12622650
]
Shalin Shekhar Mangar commented on SOLR-700:
--------------------------------------------
bq. In any case the getISO3Country method of the Locale class (among others)
throws an exception if it's invoked on an invalid locale. Maybe it would be
best to check all available locales explicitly instead of relying on the regex,
possibly by constructing a static HashMap of them?!
We don't need to be paranoid about this because if such a Locale is used for
parsing, the NumberFormat#getInstance will throw a MissingResourceException for
the lack of corresponding resource bundle.
Reading through the docs, another area I'm becoming concerned about is partial
parsing of the string. Pehaps we should use ParsePosition and verify that the
whole string was actually used. See the section on validation at
http://www.ibm.com/developerworks/java/library/j-numberformat/
> NumberFormatTransformer should have configurable locales
> --------------------------------------------------------
>
> Key: SOLR-700
> URL: https://issues.apache.org/jira/browse/SOLR-700
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Affects Versions: 1.3
> Reporter: Stefan Oestreicher
> Assignee: Shalin Shekhar Mangar
> Priority: Minor
> Fix For: 1.3
>
> Attachments:
> handler.dataimport.NumberFormatTransformer-locale.patch..txt,
> handler.dataimport.NumberFormatTransformer-locale.patch..txt,
> handler.dataimport.NumberFormatTransformer-locale.patch..txt,
> handler.dataimport.NumberFormatTransformer-locale.patch..txt,
> handler.dataimport.TestNumberFormatTransformer-locale.patch.txt,
> schema.DateField-locale.patch.txt, SOLR-700.patch
>
>
> NumberFormatTransformer uses a NumberFormatter which relies on the system
> locale. This makes it impossible to use NumberFormatTransformer with data
> whose locale does not match the system locale.
> TestNumberFormatTransformer fails on some locales for similar reasons because
> the grouping symbol differs in different locales.
> This issue adds a locale attribute for NumberFormatTransformer which allows
> the user to specify the locale which should be used for formatting. The
> locale must be specified as land-country e.g. en-US
> {code:xml}
> <field column="myNumber" formatStyle="number" locale="de-DE" />
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
