How many different groups are there? And can user A ever be part of more than one group? If 1> there are a reasonably small number of groups (< 100 or so as a place to start) and 2> a user is always part of a single group
then you could store separate prices in each document by group, thus you'd have some fields like price_group_a: $100 price_group_b: $101 then sorting becomes trivial, you just specify a sort_group_a for users in group A etc. If the number of groups is unknown-but-not-huge dynamic fields could be used. If that's not the case, then you might be able to get clever with sorting by function, here's a place to start: https://cwiki.apache.org/confluence/display/solr/Function+Queries These can be arbitrarily complex, but I'm thinking something where the price returned by the function respects the group the user is in, perhaps even the min/max of all the groups the user is in. I admit I haven't really thought that through well though... Best, Erick On Sat, Sep 20, 2014 at 9:26 AM, Scott Smith <ssm...@mainstreamdata.com> wrote: > I need to provide a custom sort option for sorting by price and I would like > some suggestions. It's not the straightforward "just sort by a price field > in the document" scenario or I wouldn't be asking for help. Here's the > scenario I'm dealing with. > > I have 100 million+ documents (so multi-sharded). Users search for documents > they are interested in using a standard keyword search. They then purchase > documents they are interested in. So far, nothing hard. > > Here's where things get "interesting". The documents come from multiple > suppliers. Each supplier sets a price for his documents and different > suppliers will provide different pricing. > > That wouldn't be difficult except that *users* are divided up into different > groups and depending on which group they are in, the supplier will charge the > user a different price. So, user A may pay one price for a document and user > B may pay a different price for the same document just because user A and > user B are in different groups. I don't even know if the relative order or > pricing is the same between different groups (e.g., if document X is more > expensive than document Y for a user in group M, it may not be more expensive > for a user in group N). The one thing that may make this doable is that > supplier A will likely have the same price for all of his documents for each > of the user groups. So, a user in group A will pay the same price regardless > of which document he buys from supplier 1. A user in group B will also pay > the same price for any document from supplier 1; it's just that a user in > group B will likely pay a different price than a user in group A. So, within > a supplier, the price varies based on user group, not the document. > > To summarize, one of the requirements for the system is that we provide the > ability to sort search results based on price. This would be easy except > that the price a user pays not only depends on what he wants to buy, but on > what group the he is in. > > I suspect there is some kind of custom solr module I'm going to have to > write. I'm thinking that the user group gets passed in as a custom solr > parameter (I'm assuming that's possible??). Then I'm thinking that there has > to be some kind of in memory database that tracks pricing based on user group > and document supplier). > > I'm happy to go read code, documents, links, etc if someone can point me in > the right direction. What kind of solr module am I likely going to write > (extend) and are there some examples somewhere? Maybe there's a way to do > this without having to extend a solr module?? > > Hope this makes sense. Any help is appreciated. > > Scott > >
