CH CH CH CH CH CHANGES.txt, no?
Please see: https://issues.apache.org/jira/browse/LUCENE-857#action_12487433
Otis
----- Original Message ----
From: Peter Keegan <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, April 6, 2007 8:38:49 AM
Subject: Re: Caching in QueryFilter - why?
>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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
