I wrote the following after hurriedly reading Grant Ingersoll's
question, and I completely missed the "to remove results that have
already been viewed" bit. Which leads me to think what I wrote may
have no bearing on this issue... but perhaps it may have bearing on
someone else's issue?
- J
: 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?
Not really ... Solr doesn't use Filter's the same way as
CachingWrapperFilter does ... it builds Doc
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 m
: > 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 an
On 4/12/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
For a given user, I would like to submit a search and return back
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
Hi,
For a given user, I would like to submit a search and return back
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 imp
