lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Keegan" <peterlkee...@gmail.com>
Subject Re: Caching in QueryFilter - why?
Date Fri, 06 Apr 2007 12:38:49 GMT
>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 <hossman_lucene@fucit.org> 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 <erik@ehatchersolutions.com>
> : 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: java-dev-unsubscribe@lucene.apache.org
> : > For additional commands, e-mail: java-dev-help@lucene.apache.org
> :
> :
> : ---------------------------------------------------------------------
> : To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> : For additional commands, e-mail: java-dev-help@lucene.apache.org
> :
> :
> :
> :
> :
> : ---------------------------------------------------------------------
> : To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> : For additional commands, e-mail: java-dev-help@lucene.apache.org
> :
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message