Of course, another approach doesn't occur to me until the weekend. But,
even if building a filter is a time-consuming process, you could always
build them as a warm-up when your searcher starts, and cache them *then*.
That way, the user doesn't see a long pause when the filter is built the
fir
Oh, yeah, you're hearing a doubtful opinion because if this kind of thing
isn't done exactly correctly, it'd be particularly hard to debug. Keeping
things coordinated is hard ...
Given that you add/remove docs, you really don't want to just modify the
filter. Here's why
All a filter is a bit
Erick wrote:
> Well, I *suppose* you could get the bitset from the pre-existing filter,
> copy it to the bitset for your new filter, and play with the bits at the
> end. I'm not sure how you get rid of your original filter if you use
> CachingWrapperFilter though.
Ok, I'm hearing it's a d
Well, I *suppose* you could get the bitset from the pre-existing filter,
copy it to the bitset for your new filter, and play with the bits at the
end. I'm not sure how you get rid of your original filter if you use
CachingWrapperFilter though.
But As "the guys" have pointed out in oth
