Hoss Man [15/Jan/07 12:16 AM]
14 jan 2007 kl. 18.18 skrev karl wettin:
I'm not certain I understand the possible effects of replacing the
searcher in an instance of Hits, but this is what I do in order to
keep cached instances valid when index is updated with changes
that does not affect the results in the Hits. I would very much
like to hear from someone about that.
i don't think the Hits.setSearcher method you added is safe ... i
believe that at a minimum hitDocs, first, last, and weight all need
to be reset -- weight's a tricky one since the instance doesn't
currently hang on to the orriginal query.
Looked in to this and came up with a perhaps better solution: adding
yet another layer of decoration of the searcher passed to the Hits at
construction time. This way the searcher can change without touching
the Hits. I.e. the decorated searcher in the searched passed to the
Hits will be replaced, and the Hits communicate with the decorator.
I'll have to write a more complex test case to make sure if this
works or not.
The problem remaining is what do to with Hits when one of the results
within this Hits is removed from the index. Perhaps the easiest way
is to extend Hits and keep track of what has been removed, but I
would prefere to modify the actual hits. For now I just remove Hits
from the cache on such events. With the hit collection cached it will
still rebuilds much faster than replacing the query. But a "native"
Hits cache would be nice.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
