On 3/10/06, eks dev <[EMAIL PROTECTED]> wrote:
> It looks to me everybody agrees here, not? If yes, it
> would be really usefull if somebody with commit rights
> could add 1) and 2) to the trunk (these patches
> practically allready exist).
Perhaps after 2.0 is out... I don't think new features ar
Hi, All,
For the filter issue, my idea is to completely get rid of the filter
interface. Can we not use the HitCollector and have that to do the filtering
work?
I am in the process of writing a simpler engine based on Lucene source code.
I don't mind re-inventing the wheel, as I feel frustrated w
It looks to me everybody agrees here, not? If yes, it
would be really usefull if somebody with commit rights
could add 1) and 2) to the trunk (these patches
practically allready exist).
It is not invasive change and there are no problems
with compatibility. Also, I have noticed a lot of
people try
: > > public interface DocIterator {
: > > public int doc();
: > > public boolean next();
: > > public boolean skipTo(int target);
: > > }
: Btw. the DocNrSkipper referred to earlier has this DocIterator functionality
: in one method:
:
: int nextDocNr(int)
:
On 1/26/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> I was suggesting an interface that would allow the
> searcher to first ask the filter "what is the lowest doc id that you
> allow?" score that doc, then say "what is the next doc id you allow?" and
> score that one.
Paul has already implemen
On Friday 27 January 2006 09:19, Morus Walter wrote:
> On Thu, 26 Jan 2006 11:33:50 -0800 (PST)
> Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> >
> > : It seems your interface requires that the SearchFilter know all of the
query
> > : results before hand. I am not sure this works well with the
On Thu, 26 Jan 2006 11:33:50 -0800 (PST)
Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> : It seems your interface requires that the SearchFilter know all of the query
> : results before hand. I am not sure this works well with the partial result
> : sets that Lucene supports.
>
> No, I'm not sug
r out of the box
public interface DocIterator {
public int doc();
public boolean next();
public boolean skipTo(int target);
}
:
: -Original Message-
: From: [EMAIL PROTECTED]
: [mailto:[EMAIL PROTECTED] Behalf Of Chris Hostetter
: Sent: Thursday, January 26, 2006
On Thursday 26 January 2006 20:08, Chris Hostetter wrote:
>
> The subject of revamping the Filter API to support more compact filter
> representations has come up in the past ... At least one patch comes to
> mind that helps with the issue...
>
>https://issues.apache.org/jira/browse/LUCENE-32
Lucene supports.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Chris Hostetter
Sent: Thursday, January 26, 2006 1:09 PM
To: java-dev@lucene.apache.org
Subject: Re: Filter
The subject of revamping the Filter API to support more compact filter
representations
The subject of revamping the Filter API to support more compact filter
representations has come up in the past ... At least one patch comes to
mind that helps with the issue...
https://issues.apache.org/jira/browse/LUCENE-328
...i'm not intimitely familiar with that code, but if i recall corr
11 matches
Mail list logo