lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Waite <>
Subject Re: Filter updating
Date Sat, 29 Jul 2006 00:10:54 GMT
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 doubtful option. ;-)

> But.... As "the guys" have pointed out in other contexts, be really sure
> your doc IDs don't change out from under you. You can only count on this if
> you never, Never, NEVER delete anything from the index and then add
> something else between the times you build the first filter and the time you
> modify it (at least I think I have this right).

In general, the above scenario is exactly what would happen. Ie. filter gets
built, sometime later a doc might be deleted (or not), then sometime later
a doc will be added (and added to the existing filter).

As it stands in the API, if I build a filter, and a document which happens to
be in it gets deleted from the index, does it automatically get removed from
the filter?

> That said, I wouldn't go down this route unless you have an actual,
> real-live performance issue to deal with. Premature optimization being the
> root of many, many, many evils. It'd be evil to debug if you mess up your
> filter copying/modification.....

Right - I'll make sure it's broken before diving in there and fixing it... ;-)


>> I was wondering if there was a nice way to add documents to a cached filter
>> 'manually' as it were.

>> The reason would be to avoid a complete refresh of the filter, if you
>> already knew the docids of the extra documents to add.

>> An example would be if I had a filter based on datetime, which contained
>> all documents since a recent fixed timestamp. Then as each new document
>> arrived, and was indexed it could be simply added to the filter quickly,
>> instead of having to rebuild it from scratch each time.

>> Cheers,
>> Paul.

"The overhead kick could have gone anywhere, but it didn't."

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message