lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2202) Money FieldType
Date Wed, 27 Oct 2010 18:39:20 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message