lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jian chen" <chenjian1...@gmail.com>
Subject Re: Filter
Date Fri, 10 Mar 2006 18:37:28 GMT
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 with the relations
among Query, Searcher, Scorer, etc.

I have done the initial round of my code already and it is in production and
works great. Basically, the search interfaces will be like the following:

public interface IndexSearcher
{
    public void search(HitCollector hc, int maxDocNum)
          throws IOException;
}

public interface HitCollector
{
  public void collect(int doc, float score);

  // the total hits that meet the search criteria,
  // could be way bigger than the actual ScoreDocs
  // we record in the HitQueue
  public int getTotalHits();

  public ScoreDoc[] getScoreDocs();

  public int getNumScoreDocs();

  // max number of ScoreDocs this hit collector could hold
  public int getCapacity();
}

I have refactored the Scorers in Lucene to be just Searchers. Because the
scorer is the actual searcher that does the ranking, right?

I will publish my code using an open source license this year.

Cheers,

Jian Chen
Lead Developer, Seattle Lighting

On 3/10/06, eks dev <eksdev@yahoo.co.uk> 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).
>
> It is not invasive change and there are no problems
> with compatibility. Also, I have noticed a lot of
> people trying to "hack in" better Filter support using
> Pauls Patches from JIRA.
>
> That would open a window for some smart code to get
> commited into Lucene core.
>
> Just have a look at Filtering support in Solr,
> beautiful, but unfortunately also "hacked" just to
> overcome BitSet on Filter.
>
>
>
>
> --- Chris Hostetter <hossman_lucene@fucit.org> wrote:
>
> >   1) commit DocNrSkipper interface to the core code
> > base
> >   2) add the following method declaration to the
> > Filter class...
> >         public DocNrSkipper getSkipper(IndexReader)
> > throws IOException
> >      ...impliment this method by calling bits, and
> > returning an instance
> >      of BitSetSortedIntList
> >   3) indicate that Filter.bits() is deprecated.
> >   4) change all existing calls to Filter.bits() in
> > the core lucene code
> >      base to call Filter.getSkipper and do whatever
> > iterating is
> >      neccessary.
> >   5) gradually reimpliment all of the concrete
> > instances of Filter in
> >      the core lucene code base so they override the
> > getSkipper method
> >      with something that returns a more "iterator"
> > style DocNrSkipper,
> >      and impliment their bits() method to use the
> > DocNrSkipper from the
> >      new getSkipper() method to build up the bit set
> > if clients call it
> >      directly.
> >   6) wait a suitable amount of time.
> >   7) remove Filter.bits() and all of the concrete
> > implimentations from the
> >      lucene core.
> >
> >
> >
> >
> > -Hoss
> >
> >
> >
>
>
>
> ___________________________________________________________
> To help you stay safe and secure online, we've developed the all new
> Yahoo! Security Centre. http://uk.security.yahoo.com
>
> ---------------------------------------------------------------------
> 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