[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225493#comment-13225493
]
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 & facet.range.gap=200,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: 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
> 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: http://wiki.apache.org/solr/MoneyFieldType
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
