: With this approach now I can boost (i.e. multiply Solr's score by a factor) : the results of any query by doing something like this: : http://localhost:8080/solr/Prueba/select_test?q={!boost : b=rating(usuario1)}text:grapa&fl=score : : Where 'rating' is the name of my function. : : Unfortunately, I still can't see which differences are between doing this or : making the product of both scores as the value for the query's sort : parameter... :(
I'm not sure i understand your question. With the example query above, your score -- both returned, and used for sorting by score -- is the mathematical result of multiplying your function by the relevancy score of "text:grapa" Perhaps what you are refering to is the idea that if you wnat the "score" to remain purely about relevancy, you can still opionally sort on the results of this function, by using the function solely in your sort -- the only thing that tends to confuse people here is how you refer back to the original query in that "sort by function" command... http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201206.mbox/%3Calpine.DEB.2.00.1206111242260.17925@bester%3E or in your case, something like this would return the both the raw score, and your custom rating, but it would sort on the product of those two values... ?q=text:grapa&fl=id,score,rating(usuario1)&sort=product(rating(usuario1),query($q) : Which is the best place to do it? I think I would query the DB/cache just : when the custom ValueSource is created in the ValueSourceParser's parse That might makes sense, but becareful where you put this cache data -- if it's part of the ValueSource then whenever that ValueSource is used in a FunctionQuery (ie: "{!boost b=rating(usuario1)}text:grapa" it will be part of the cache key for the queryResultCache or filterCache -- so having large data structures in your ValueSource could eat up a lot of RAM. Take a look at src/docs/differences between the ValueSource class and the FunctionValues class -Hoss
