[
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: [email protected]
For additional commands, e-mail: [email protected]
