lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1849) Add OutOfOrderCollector and InOrderCollector subclasses of Collector
Date Mon, 24 Aug 2009 19:44:59 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747039#action_12747039
] 

Tim Smith commented on LUCENE-1849:
-----------------------------------

bq. I think this will get pretty messy and complicated.

yeah, this is a bit messy with the chain of inheritance in these classes (as each variant
is "slightly" optimized depending on in order/out of order collection)

makes me go back to favoring InOrderCollector/OutOfOrderCollector abstract classes
or maybe just one "AbstractCollector" method which implements all methods except collect()

like so:
{code}
public abstract class AbstractCollector extends Collector {
  private final boolean allowDocsOutOfOrder;
  protected IndexReader reader;
  protected Scorer scorer;
  protected int docBase;  

  public AbstractCollector() {
    this(false);
  }

  public AbstractCollector(boolean allowDocsOutOfOrder) {
    this.allowDocsOutOfOrder = allowDocsOutOfOrder;
  }

  public void setNextReader(IndexReader reader, int docBase) {
    this.reader = reader;
    this.docBase = docBase;
  }

  public void setScorer(Scorer scorer) {
    this.scorer = scorer;
  }

  public final boolean acceptsDocsOutOfOrder() {
    return allowDocsOutOfOrder;
  }
}
{code}

bq. What exactly are we trying to solve here?
the Collector methodology has grown more complicated (because it does more to handle per segment
searches)
the HitCollector api was nice and simple

this AbstractCollector (insert better name here) gets things back to being more simple
could even hide the "Scorer" as private and provide a "score()" method that returns the score
for the current document, and otherwise simplify this even more

subclassing AbstractCollector instead of Collector makes it so most of the "required common
things" are done for you
otherwise, every single Collector will do virtually the same thing is done in AbstractCollector
here (as far as setup/etc)

Again, this is just a _Wish_ which i've thought of as i've been working through the new collector
API (and found myself doing the exact same thing for every implementation of Collector)


> Add OutOfOrderCollector and InOrderCollector subclasses of Collector
> --------------------------------------------------------------------
>
>                 Key: LUCENE-1849
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1849
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Search
>    Affects Versions: 2.9
>            Reporter: Tim Smith
>            Priority: Minor
>             Fix For: 2.9
>
>
> I find myself always having to implement these methods, and i always return a constant
(depending on if the collector can handle out of order hits)
> would be nice for these two convenience abstract classes to exist that implemented acceptsDocsOutOfOrder()
as final and returned the appropriate value

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message