[jira] Commented: (LUCENE-857) Remove BitSet caching from QueryFilter
[ https://issues.apache.org/jira/browse/LUCENE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487679 ] Hoss Man commented on LUCENE-857: - I don't think it's a question of being careless about reading the Changelog -- I just think that when dealing with a point release, we shouldn't require people to make code changes just to get the same behavior as before ... if this was necessary to fix a bug it would be one thing, but really what we're talking about here is refactoring out a piece of functionality (using a Query as a Filter) so that it can be used independently from another piece of functionality (filter caching) ... since that can be done in a backwards compatible way, why not make it easy for people. With your suggestion one can't get a raw QueryFilter without getting it automatically cached. Isn't this inflexibility uncool? ...not quite, I'm suggesting that the raw QueryFilter behavior be extracted into a new class (QueryWrapperFilter) and the existing QueryFilter class continue to do exactly what it currently does - but refactored so that there is no duplicate code. Remove BitSet caching from QueryFilter -- Key: LUCENE-857 URL: https://issues.apache.org/jira/browse/LUCENE-857 Project: Lucene - Java Issue Type: Improvement Reporter: Otis Gospodnetic Assigned To: Otis Gospodnetic Priority: Minor Attachments: LUCENE-857.patch 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 the CachingWrapperFilter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-857) Remove BitSet caching from QueryFilter
[ https://issues.apache.org/jira/browse/LUCENE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487433 ] Otis Gospodnetic commented on LUCENE-857: - I think this is where a javadoc and CHANGES.txt come in. People with serious production environments don't just throw new Lucene version on top of the old one without carefully reading CHANGES.txt. I do this every time I upgrade. If one is careless and doesn't read that, then, well... What you suggested is okay, but I didn't want to deprecate the whole class, just remove the caching concern from it, as that's what the CWF is concerned with already. With your suggestion one can't get a raw QueryFilter without getting it automatically cached. Isn't this inflexibility uncool? Remove BitSet caching from QueryFilter -- Key: LUCENE-857 URL: https://issues.apache.org/jira/browse/LUCENE-857 Project: Lucene - Java Issue Type: Improvement Reporter: Otis Gospodnetic Assigned To: Otis Gospodnetic Priority: Minor Attachments: LUCENE-857.patch 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 the CachingWrapperFilter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-857) Remove BitSet caching from QueryFilter
[
https://issues.apache.org/jira/browse/LUCENE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487116
]
Hoss Man commented on LUCENE-857:
-
From email since i didn't notice Otis opened this issue already...
Date: Thu, 5 Apr 2007 14:24:31 -0700 (PDT)
To: java-dev@lucene.apache.org
Subject: Re: Caching in QueryFilter - why?
: 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)
Remove BitSet caching from QueryFilter
--
Key: LUCENE-857
URL: https://issues.apache.org/jira/browse/LUCENE-857
Project: Lucene - Java
Issue Type: Improvement
Reporter: Otis Gospodnetic
Assigned To: Otis Gospodnetic
Priority: Minor
Attachments: LUCENE-857.patch
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 the
CachingWrapperFilter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
