[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925494#action_12925494
]
Robert Muir commented on SOLR-2202:
-----------------------------------
bq. However, I think including the currency code as part of the value itself
(particularly when indexing it as a field) is an important use case to support
as well, since it makes indexing so much easier to implement. Is this what you
mean by Solr taking the ISO code as input? For example: "price:10.00USD", where
the code is part of the value.
No, I don't think we should do this.
I think the code, even in this case should be provided separate.
Because 10.00USD is just still a number format (NumberFormat.ISOCURRENCYSTYLE),
not any less ambiguous than $10.00 (NumberFormat.CURRENCYSTYLE) to me.
Under a chinese locale its USD10.00, under german its 10,00 USD (with a space!)
Really I can't stand how the current date-range stuff is handled by Lucene
either via queryparsing.
In my opinion, when queryparsing this stuff: for a date range query/indexing,
you should have to provide a DateFormat.
for a currency query/indexing, you should have to provide a DecimalFormat.
For dates, it seems Solr opted to go with a standardized required DateFormat
across the board, and its up to clients to convert.
We really need to think this through for Currency, because passing the
necessary stuff to build a DecimalFormat its going to be verbose (Locale +
Currency ISO Code + Format String + the String containing the currency value
itself)...
Really I wonder if we could force the client to deal with localization and
parsing, since thats where it fits best anyway, and make it provide just the
raw long + ISO code to solr for this...
the fact that Solr forces you to implement query-parsing server-side is going
to introduce complexity here unless we can find a trick...
> Money FieldType
> ---------------
>
> Key: SOLR-2202
> URL: https://issues.apache.org/jira/browse/SOLR-2202
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
> Affects Versions: 1.5
> Reporter: Greg Fodor
> Attachments: SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch,
> SOLR-2202-solr-2.patch
>
>
> Attached please find patches to add support for monetary values to
> Solr/Lucene with query-time currency conversion. The following features are
> supported:
> - Point queries (ex: "price:4.00USD")
> - Range quries (ex: "price:[$5.00 TO $10.00]")
> - Sorting.
> - Currency parsing by either currency code or symbol.
> - Symmetric & Asymmetric exchange rates. (Asymmetric exchange rates are
> useful if there are fees associated with exchanging the currency.)
> At indexing time, money fields can be indexed in a native currency. For
> example, if a product on an e-commerce site is listed in Euros, indexing the
> price field as "10.00EUR" will index it appropriately. By altering the
> currency.xml file, the sorting and querying against Solr can take into
> account fluctuations in currency exchange rates without having to re-index
> the documents.
> The new "money" field type is a polyfield which indexes two fields, one which
> contains the amount of the value and another which contains the currency code
> or symbol. The currency metadata (names, symbols, codes, and exchange rates)
> are expected to be in an xml file which is pointed to by the field type
> declaration in the schema.xml.
> The current patch is factored such that Money utility functions and
> configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig),
> while the MoneyType and MoneyValueSource lie in Solr. This was meant to
> mirror the work being done on the spacial field types.
> This patch has not yet been deployed to production but will be getting used
> to power the international search capabilities of the search engine at Etsy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
