I don't use Filters very much so this might be a dumb question, but I
could overcome the main drawback by hooking into the filter and
updating it's bits without affecting the caching, right?
I kind of think I have scaling issues no matter what. If you do the
post processing way, then you may have to make repeated fetches to
Solr in order to get enough results to display.
I think I may have to dig a bit deeper into both approaches
On Apr 12, 2007, at 7:41 PM, Chris Hostetter wrote:
: > 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
