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!
