Hi Paul,
W.r.t. ConstantScoringQuery, it contains a minor bug: it doesn't the
handle the case where the Filter.bits method would return null. I think
the ConstantScorer should look like:
public boolean next() throws IOException {
doc = (bits == null) ? doc+1 : bits.nextSetBit(doc+1);
> W.r.t. ConstantScoringQuery, it contains a minor bug: it doesn't the
> handle the case where the Filter.bits method would return null.
Can Filter.bits() ever return null though? AFAIK, that's not in the contract.
The Filter.getBits() javadoc says:
Returns a BitSet with true for docum
: I have the same problem with HitCollector: I'd need to go through /all/
: documents.
Are you sure about that? I'm fairly certain that IndexSearcher will never
give your HitCollector a doc to collect unless that doc matches the query.
(Note: i seem to recall that it is possibel you'll be given
On Sunday 18 December 2005 15:46, Cret Hummin wrote:
> Hi Paul,
>
> W.r.t. ConstantScoringQuery, it contains a minor bug: it doesn't the
> handle the case where the Filter.bits method would return null. I think
> the ConstantScorer should look like:
>
> public boolean next() throws IOExcept
Hi Paul,
W.r.t. ConstantScoringQuery, it contains a minor bug: it doesn't the
handle the case where the Filter.bits method would return null. I think
the ConstantScorer should look like:
public boolean next() throws IOException {
doc = (bits == null) ? doc+1 : bits.nextSetBit(doc+1);
On Saturday 17 December 2005 17:04, Cret Hummin wrote:
> Hi All,
>
> When using Searcher.search(Query, Filter), and I use my own custom
> filter, it appears I'm presented with /all/ the documents in the index,
> i.e. in the method bits(IndexReader reader) from my custom Filter, the
> value of r
