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/

Reply via email to