this seems like a potentially big surprise for people when upgrading ...
old code will continue to work fine without warning, just get a lot less
efficient.
I agree. This would certainly be a big surprise to anyone not following this
forum closely (like me - I just happened to stumble upon this thread). A
deprecation strategy would be more palatable.
Peter
On 4/5/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Since caching is built into the public BitSet bits(IndexReader reader)
: method, I don't see a way to deprecate that, which means I'll just cut
: it out and document it in CHANGES.txt. Anyone who wants QueryFilter
: caching will be able to get the caching back by wrapping the QueryFilter
: in your CachingWrapperFilter.
this seems like a potentially big surprise for people when upgrading ...
old code will continue to work fine without warning, just get a lot less
efficient.
If the concern is duplicated code, perhaps QueryFilter should be
deprecated and changed to be a subclass of CachingWrapperFilter, with a
constructor that takes in the Query and wraps it in some new class
(QueryWrapperFilter perhaps?) that does the meaty part (collecting the
matches) ...
@deprecated use CachingWrapperFilter and QueryWrapperFilter directly
public class QueryFilter extends CachingWrapperFilter {
public QueryFilter(Query query) {
super(new QueryWrapperFilter(query));
}
}
public class QueryWrapperFilter extends Filter {
private Query query;
public QueryWrapperFilter(Query query) {
this.query = query;
}
public BitSet bits(IndexReader reader) throws IOException {
final BitSet bits = new BitSet(reader.maxDoc());
new IndexSearcher(reader).search(query, new HitCollector() {
public final void collect(int doc, float score) {
bits.set(doc); // set bit for hit
}
});
return bits;
}
}
(obviously we need some toString, equals, and hashCode methods in here as
well)
:
:
: Otis
: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
: Simpy -- http://www.simpy.com/ - Tag - Search - Share
:
: ----- Original Message ----
: From: Erik Hatcher <[EMAIL PROTECTED]>
: To: java-dev@lucene.apache.org
: Sent: Wednesday, April 4, 2007 7:38:00 PM
: Subject: Re: Caching in QueryFilter - why?
:
: CachingWrapperFilter came along after QueryFilter. I think I added
: CachingWrapperFilter when I realized that every Filter should have
: the capability to be cached without having to implement it. So, the
: only reason is "legacy". I'm perfectly fine with removing the
: caching from QueryFilter in a future major release.
:
: Erik
:
: On Apr 4, 2007, at 5:57 PM, Otis Gospodnetic wrote:
:
: > Hi,
: >
: > I'm looking at LUCENE-853, so I also looked at CachingWrapperFilter
: > and then at QueryFilter. I noticed QueryFilter does its own BitSet
: > caching, and the caching part of its code is nearly identical to
: > the code in CachingWrapperFilter.
: >
: > Why is that? Is there a good reason for that?
: >
: > Thanks,
: > Otis
: > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
: > Simpy -- http://www.simpy.com/ - Tag - Search - Share
: >
: >
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: [EMAIL PROTECTED]
: > For additional commands, e-mail: [EMAIL PROTECTED]
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: [EMAIL PROTECTED]
: For additional commands, e-mail: [EMAIL PROTECTED]
:
:
:
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: [EMAIL PROTECTED]
: For additional commands, e-mail: [EMAIL PROTECTED]
:
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
