(this is theoretical, rather than practice-based reasoning, others may have better ideas).
You seem to have several issues. The displayed currency seems to be an independent variable from anything else (bad) that is a uniform scale for all prices (good). So, I would keep that out of Solr and perhaps normalize all prices internally into one base currency. So, store all prices and vats and taxes normalized into USD, RMB or virtual currency. Convert it to the local currency on display and convert from local currency on the range numbers before doing the search (e.g. in Search component or on the client). For the VAT, I assume different items probably attract different taxation rules based on both item and country. E.g. not uniform x% per country, but x% for some products, y% for others, 0% for yet others. And then you want efficient filtering and/or faceting, which means those final combined individual numbers really need to be present in the Lucene data structures. Which - to me - implies pre-calculation of those permutations and have them as the documents you store. So, perhaps have a parent with product details and a bunch of children records with 'local_pricing' data. I realize that blows the records size up a lot, but if you don't store much/anything in the child records, it may not be too bad. Hope this helps, Alex. ---- http://www.solr-start.com/ - Resources for Solr users, new and experienced On 31 January 2017 at 10:32, Ugo Matrangolo <ugo.matrang...@gmail.com> wrote: > Hi > > I'm working on app where we use Solr for our search. > > Items out of the search have to be price personalized based on the > country/ip/locale of the customer (e.g. configured currency in its settings > + duties & VAT for his/her country). We also need to filter on a price > range that has to take in account the base price + all the duties and vat > due in the customer country (when the user filters 50$ TO 100$ we need to > factor in duties & vat). > > The idea is to decorate the search response at query time calling a > separate service to retrieve all the info we need but we are a bit confused > on the best place to put this logic. > > We reckon we have two options: > > 1. Write a Search Component that gets configured in the middle of the > search request to add a 'sku_personalized_price' in the search results > (this will work out of the box with stats comp and fq, we assume). > > 2. Use filter queries to do the same and frange for filtering. > > We are curious if someone else had to do the same and what are (if any) > best practices in this (reasonably common) scenario. > > Please note that we need also to offer the ability to filter on price and > we need to filter on base price + tax + duties. > > WDYT ? > > Best > Ugo
