: > results that are filtered on a per user basis, for instance to remove : > results that have already been viewed. I know I could post process : > the results from Solr to do this, but am wondering if a better : > solution is to implement my own request handler that takes in user id : > info and manages a cache of Filters that maintains the bit set info : > on the search side. Is this a good approach?
: One issue with your approach would be scaling... if you have multiple : searchers, how do you communicate this user data between them? If the filtering logic can be implemented in a Filter class, you might just want to rely on the built in filterCache (you'd still need a custom request handler that kows about your custom Filter) the plus side is you'd get all the benefits of Solr's filter cache (cached as long as the same searcher is used, autowarmed when a new searcher is opened) the down side is you'd get all the benefits of Solr's filter cache (cached as long as the same searcher is used -- so it wouldn't notice if you'd updated your datastore to remove a bunch of files from their filter) -Hoss
