lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Rafalovitch <arafa...@gmail.com>
Subject Re: Results personaliazation
Date Tue, 31 Jan 2017 16:06:04 GMT
(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.matrangolo@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

Mime
View raw message