[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925488#action_12925488
]
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: 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
