I'll take a look at that. Thanks -----Original Message----- From: Apoorva Gaurav [mailto:apoorva.gau...@myntra.com] Sent: Sunday, September 21, 2014 11:32 PM To: solr-user Subject: Re: Help on custom sort
Try using a custom value source parser and pass the "formula" of computing the price to solr; something like this http://java.dzone.com/articles/connecting-redis-solr-boosting On Mon, Sep 22, 2014 at 1:38 AM, Scott Smith <ssm...@mainstreamdata.com> wrote: > There are likely several hundred groups. Also, new groups will be > added and some groups will be deleted. So, I don't think putting a > field in the docs works. Having to add a new group price into 100 > million+ documents doesn't seem reasonable. > > Right now I'm looking at > http://sujitpal.blogspot.com/2011/05/custom-sorting-in-solr-using-external.html. > This reference a much older version of solr (the blog is from 2011) > and so I will need to update the classes referenced. > > -----Original Message----- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Saturday, September 20, 2014 11:58 AM > To: solr-user@lucene.apache.org > Subject: Re: Help on custom sort > > 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 > > > > > -- Thanks & Regards, Apoorva
