lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Fodor (JIRA)" <>
Subject [jira] Commented: (SOLR-2202) Money FieldType
Date Wed, 27 Oct 2010 18:21:20 GMT


Greg Fodor commented on SOLR-2202:

Uwe: apologies if I'm missing something, but I'm still having a hard time understanding how
this would work. If the user performs a query for 10.00EUR, it seems the appropriate trie
range, in theory, would be the largest and smallest possible converted currency value, across
all currencies. For example, if we assume currencies 1FOO = 100EUR, and 1BAR = 0.001EUR, then
we'd have to do a trie range for the query 1EUR from 0.001 to 100, is this correct?

If this is what you're proposing, I'm not sure if it will be that big a win, due to the fact
that there are exchange rates exceeding 100X (for example, USD -> JPY). Presumably, if
you are indexing e-commerce products that range from say $10.00 to $1,000USD, you'll likely
be forced to scan the entire range of values for most queries. For example, a $25.00USD query
will need to scan from approx 10.00 -> 2500.00 to be sure no documents are missed. (lower
bound dictated by GBP or EUR, upper bound by JPY for example.)

Robert: Thanks for the clarifications. First, if no such mechanism exists, would it make sense
to include the locale as one of the parameters to the query via the edismax parser? I think
the locale specified can be useful for parsing the currency in cases where "$", for example,
is ambiguous, and we should defer as you said to the ICU/Java parser. 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. This is what is currently supported by the patch. Note
that I do not allow spaces, since that breaks the range query parser. ("price:[10.00USD to
40.00USD]") This can probably be addressed later.

> Money FieldType
> ---------------
>                 Key: SOLR-2202
>                 URL:
>             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:
For additional commands, e-mail:

View raw message