Hi, tx for the reply.
Unfortunately storing/pre-calculating personalized prices and storing in the index is out of the question; in the near future we could have some other variables that changes per user/per request. Also, the docs we store are beefy and we really would love to avoid to pollute the index with redundant info. Also, we already have an external svc that will do all the pricing logic and we def need to avoid to duplicate code in search. The idea so far is to store prices in a default currency (USD), perform the query, decorate the search results using a search component that scans through the doclist and for each doc applies a pricer obj we get from the external svc (no worry, these objects are cacheable). This way we should be able to dynamically add a 'personalized_price' field to the returned docs and then get for free filter queries/stats and so on. Lots of assumption but this is the best idea so far. Another option is to apply the same logic but late on in the query chain: using function queries and frange. WDYT ? Best Ugo On Tue, Jan 31, 2017 at 4:06 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > (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 >
