Couldn't you use a custom HitCollector?
For example, you could maintain an array of floats which is the current rating for each document. You'd need to rebuild this array each time the index is altered, but you could maintain it incrementally as documents are viewed. Then your HitCollector can multiply this into the score or somesuch. Similarly, for external sort criteria, you can keep an array of the sort value for each document that is used by a HitCollector that only collects values in the desired range. The same technique should be usable for permissions too.
These are much like Filters, a cached array indexed by document id, but are instead explicitly used by application logic in a HitCollector. Could such a technique be applicable? Or would it be too hard to maintain these arrays?
Hmm. It may be possible to do this in combination with the searchbean or something similar. We'de have to maintain a reverse documentID -> UID map for every document for this to work (otherwise it would still require calling doc(i) for every (uncached) document to lookup our stored UID for the document). The amount of work required to make this work would not be insignificant and given our time constraints I don't think I'll have time to test this idea out until our next major release(s). I'll have to stick with using our current approach but using a single IndexReader and my suggested change to the FieldsReader class for the time being.
Thanks for the ideas, they are very much appreciated.
Regards,
Bruce Ritchie
smime.p7s
Description: S/MIME Cryptographic Signature
