Hi Emir,
could this be done with Pivot faceting?
The idea is to use facet.pivot=price_USER_ID,price. Then I should get all
values + number of matching documents for price_USER_ID (sub-faceted by
price, which I can just ignore). Additionally, there should be one facet
value for price_USER_ID for all documents without this field. Due to the
Pivot facet the price_USER_ID=unknown will then be further faceted with the
values of the price field. I can then sum up the number of matching
documents for each value from either price_USER_ID or price (or both) and
present that to the user. Like this:
price_USER_ID: 5$ (2 matching documents)
price_USER_ID: 3 (1)
price_USER_ID: unknown (4)
price: 5 (3)
price: 2 (1)
So the facets presented to the user will be:
price: 5 (5) // 2+3=5
price: 3 (1)
Then when the user selects price:5 the filter query will be (as you
suggested above): price_USER_ID:5 OR (-price_USER_ID:[* TO *] AND price:5)
Do you think this will work? Any idea what the performance might be like?
Best,
Georg
Emir Arnautovic <emir.arnauto...@sematext.com> schrieb am Mo., 28. März
2016 um 13:56 Uhr:
> Hi Georg,
> I cannot think of similar trick that would enable you to facet on all
> values (other than applying this trick to buckets of size 1) but would
> warn you about faceting of high cardinality fields such as price. Not
> sure if you have some specific case, but calculating facet for such
> field can be pretty expensive and slow.
> I haven't look at it in details, but maybe you could find something
> useful in new Json facet API.
>
> Regards,
> Emir
>
> On 26.03.2016 12:15, Georg Sorst wrote:
> > Hi Emir,
> >
> > that sounds like a great idea and filtering should be just fine!
> >
> > In our case we need the individual price values (not the buckets), just
> > like facet.field=price but with respect to the user prices. Is this
> > possible as well?
> >
> > About the performance: Are there any specific bottlenecks you would
> expect?
> >
> > Best regards,
> > Georg
> >
> > Emir Arnautovic <emir.arnauto...@sematext.com> schrieb am Fr., 25. März
> > 2016 um 11:47 Uhr:
> >
> >> Hi Georg,
> >> One solution that could work on existing schema is to use query faceting
> >> and queries like (for USER_ID = 1, bucker 100 to 200):
> >>
> >> price_1:[100 TO 200] OR (-price_1:[* TO *] AND price:[100 TO 200])
> >>
> >> Same query is used for filtering. What you should test is if
> >> performances are acceptable.
> >>
> >> Thanks,
> >> Emir
> >>
> >> On 24.03.2016 22:31, Georg Sorst wrote:
> >>> Hi list,
> >>>
> >>> we use Solr to search ecommerce products.
> >>>
> >>> Items have a default price which can be overwritten per user. So when
> >>> searching we have to return the user price if it is set, otherwise the
> >>> default price. Same goes for building facets and when filtering by
> price.
> >>>
> >>> What's the best way to achieve this in Solr? We know the user ID when
> >>> sending the request to Solr so we could do something like this:
> >>>
> >>> * Add the default price in the field "price" to the items
> >>> * Add all the user prices in a field like "price_<USER_ID>"
> >>>
> >>> Now for displaying the correct price this is fine, just look if there
> is
> >> a
> >>> field "price_<USER_ID>" for this result item, otherwise just display
> the
> >>> value of the "price" field.
> >>>
> >>> The tricky part is faceting and filtering. Which field do we use?
> >>> "price_<USER_ID>"? What happens for users that don't have a user price
> >> set
> >>> for an item? In this case the "price_<USER_ID>" field does not exist so
> >>> faceting and filtering will not work.
> >>>
> >>> We thought about adding a "price_<USER_ID>" field for every item and
> >> every
> >>> user and fill in the default price for the item if the user does not
> have
> >>> an overwritten price for this item. This would potentially make our
> index
> >>> unnecessarily large. Consider 10,000 items and 10,000 users (quite
> >>> realistic), that's 100,000,000 "price_<USER_ID>" fields, even though
> >> maybe
> >>> only a few users have overwritten prices.
> >>>
> >>> What I've been (unsuccessfully) looking for is some sort of field
> >> fallback
> >>> where I can tell Solr something like "use price_<USER_ID> for the
> >> results,
> >>> facets and filter queries, and if that does not exist for an item, use
> >>> price instead". At first sight field aliases seemed like that but turns
> >> out
> >>> that just renames the field in the result items.
> >>>
> >>> So, is there something like this or is there a better solution anyway?
> >>>
> >>> Thanks,
> >>> Georg
> >> --
> >> Monitoring * Alerting * Anomaly Detection * Centralized Log Management
> >> Solr & Elasticsearch Support * http://sematext.com/
> >>
> >> --
> > *Georg M. Sorst I CTO*
> > FINDOLOGIC GmbH
> >
> >
> >
> > Jakob-Haringer-Str. 5a | 5020 Salzburg I T.: +43 662 456708
> > E.: g.so...@findologic.com
> > www.findologic.com Folgen Sie uns auf: XING
> > <https://www.xing.com/profile/Georg_Sorst>facebook
> > <https://www.facebook.com/Findologic> Twitter
> > <https://twitter.com/findologic>
> >
> > Wir sehen uns auf dem *Shopware Community Day in Ahaus am 20.05.2016!*
> Hier
> > <berat...@findologic.com?subject=Terminvereinbarung%20SCD> Termin
> > vereinbaren!
> > Wir sehen uns auf der* dmexco in Köln am 14.09. und 15.09.2016!* Hier
> > <berat...@findologic.com?subject=Terminvereinbarung%20dmexco> Termin
> > vereinbaren!
> >
>
> --
> Monitoring * Alerting * Anomaly Detection * Centralized Log Management
> Solr & Elasticsearch Support * http://sematext.com/
>
> --
*Georg M. Sorst I CTO*
FINDOLOGIC GmbH
Jakob-Haringer-Str. 5a | 5020 Salzburg I T.: +43 662 456708
E.: g.so...@findologic.com
www.findologic.com Folgen Sie uns auf: XING
<https://www.xing.com/profile/Georg_Sorst>facebook
<https://www.facebook.com/Findologic> Twitter
<https://twitter.com/findologic>
Wir sehen uns auf dem *Shopware Community Day in Ahaus am 20.05.2016!* Hier
<berat...@findologic.com?subject=Terminvereinbarung%20SCD> Termin
vereinbaren!
Wir sehen uns auf der* dmexco in Köln am 14.09. und 15.09.2016!* Hier
<berat...@findologic.com?subject=Terminvereinbarung%20dmexco> Termin
vereinbaren!
