lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2202) Money FieldType
Date Thu, 08 Mar 2012 20:57:57 GMT


Hoss Man commented on SOLR-2202:

a) CurrencyField (and by extension "CurrencyValue") gets my vote

b) i really only reviewed the facet stuff in SOLR-2202-solr-10.patch (i know Jan has already
been reviewing the more core stuff about the type) ... it makes me realize that we really
need to refactor the range faceting code to be easier to do in custom FieldTypes, but that's
certainly no fault of this issue and can be done later.

The facet code itself looks correct but my one concern is that (if i'm understanding all of
this MoneyValue conversion stuff correctly) it _should_ be possible to facet with start/end/gap
values specified in any currency, as long as they are all consistent -- but there is not test
of this situation.  the negative test only looks at using an inconsistent gap, and the positive
tests only use USD, or the "default" which is also USD.  We should have at least one test
that uses something like EUR for start/end/gap and verifies that the counts are correct given
the conversion rates used in the test.

incidentally: I don't see anything actually enforcing that start/end are in the same currency
-- just that gap is in the same currency as the values it's being added to, so essentially
that start and gap use hte same currenty.  But I'm actually not at all clear on why there
is any attempt to enforce that the currencies used are the same, since the whole point of
the type (as i understand it) is that you can do conversions on the fly -- it may seem silly
for someone to say {{facet.range.start=0,USD &,EUR & facet.range.end=1000,YEN}}
but is there any technical reason why we can't let them do that?
> Money FieldType
> ---------------
>                 Key: SOLR-2202
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: Schema and Analysis
>    Affects Versions: 1.5
>            Reporter: Greg Fodor
>            Assignee: Jan H√łydahl
>             Fix For: 3.6, 4.0
>         Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch,
SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch,
SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch
> Provides support for monetary values to Solr/Lucene with query-time currency conversion.
The following features are supported:
> - Point queries
> - Range quries
> - 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 "1000,EUR" 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 will be getting used to power the international search capabilities of the
search engine at Etsy.
> Also see WIKI page:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message