On 10/25/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : The typical use case, though, is for the featured document to be on top only > : for certain queries. Like in an intranet where someone queries 401K or > : retirement or similar, you want to feature a document about benefits that > : would otherwise rank really low for that query. I have not be able to make > : sorting strategies work very well. > > this type of question typically falls into two use cases: > 1) "targeted ads" > 2) "sponsored results" > > in the targeted ads case, the "special" matches aren't part of the normal > flow of results, and don't fit into pagination -- they always appera at > the top, or to the right, on every page, no matter what the sort .... this > kind of usage doesn't really need any special logic, it can be solved as > easily by a second Solr hit as it can by custom request handler logic. > > in the "sponsored results" use case, the "special" matches should appear > in the normal flow of results as the #1 (2, 3, etc) matches, so that they > don't appear on page#2 ... but that also means that it's extremely > disconcerting for users if those matches are still at the top when the > userse resort. if a user is looking at product listings, sorted by > "relevancy" and the top 3 results all say they are "sponsered" that's fine > ... but if the user sort by "price" and those 3 results are still at teh > top of the list, even though they clearly aren't the chepest, that's just > going to piss the user off. > > in my profesional opinion: don't fuck with your users. default to > whatever order you want, but if the user specificly requests to sort the > results by some option, do it. > > assuming you follow my professional opinion, then "boosting" docs to have > an artifically high score will work fine. > > if you absolutely *MUST* have certain docs "sorting" before others, > regardless of which sort option the user picks, then it is still possible > do ... i'm hesitant to even say how, but if people insist on knowing... > > > > allways sort by score first, then by whatever field the user wants to sort > by ... but when the user wants to sort on a specific field, move the users > main query input into an "fq" (so it doesn't influence the score) ... and > use an extremely low boost matchalldocs query along with your "special doc > matching query" as the main (scoring) query param. the key being that > even though your primary sort is on score, every doc except your special > matches have identical scores.
That sorts by relevance for your sponsored results, right? What if you want absolute ordering based on dollars spent on that result, for example. > (this may not be possible with dismax because it's not trivial to move > the query into an fq Should be easier in trunk: fq=<!dismax>foo bar or fq=<!dismax v=$userq> -Yonik
