: Thats what i discovered. The question is : Is the ValueSourceQuery
: strong and fast enough to be
: used confidently in a production environment? I looked at the source
as i mentioned, i'm not intimately familiar with the new
ValueSourceQuery,
but the FunctionQuery it's based on is certainly production
quality. I
use it all over the place.
: What's wrong with this idea :
: Each day i generate an shuffle a vector of Maxdoc integers from 0 to
: Maxdoc.
:
: Then i use a valueSource query with a valueSource that uses this
: vector to randomly score the documents.
: Of course I have to somehow normalize those random scores so that
: their "contribution factor" remains constant when MaxDocs increases.
well, that's a random fixed ordering per day ... a bit different then
random per search (much more cachable).
I also didn't realize you wanted the randomness to just be an added
factor
in your orriginal query -- i thought this was a seperate "sort
randomly"
side question. your approach sounds like it it could work, but as you
say: there are complexities of keeping it balanced.
-Hoss
Thanks for your help! I will start implementing those solutions now.
One last remark :
for the "recentness" aspect a
ValueSourceQuery composed on a ReverseOrdFieldSource should take
care of
things ...
I have a problem with this solution : Document ordering is different
from Recentness :
If i upload 1000 images now, they should have the same "recentness",
even if their order is very different.
So i think i will store image dates as Int and use a field cache to
compute a score based on the difference between the present date and
the date of the image.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
