At 01:35 PM 11/15/2006, you wrote:
On 11/15/06, Tom <[EMAIL PROTECTED]> wrote:
It looks like that for trimming, the places I want to modify are in
ScorePriorityQueue and FieldSortedHitQueue. When trimming, I want to
return the top item in the group that matches, whether by score or
sort, not just the first one that goes through the HitCollector.
Wouldn't you actually need a priority queue per group?
I'm still playing with implementations, but I think you just need a
max score for each group.
You can't just do a PrioirtyQueue (of either max, or PriorityQueues)
since I don't think the Lucene PriorityQueue handles entries whose
value changes after insertion.
But, unsurprisingly, trimming vs. not trimming is being ignored with
regard to caching. How would I indicate that a query with trim=0 is
not the same as trim=1? I do still want to cache.
One hack: implement a simple query that delegates to another query and
encapsulates the trim value... that way hashCode/equals won't match
unless the trim does.
Not sure what you mean by "delegates to another query". Could you
clarify or give me a pointer?
I was thinking in terms of just adding some guaranteed true clause to
the end when trimming, is that similar to what you were talking about?
Thanks,
Tom
-Yonik
But obviously, my
implementation won't work at the moment, since all queries will cache
the value generated using the results generated by the value of trim
on the initial query.
Any suggestions for where to go poking around to fix this vs. caching?
Thanks,
Tom
