[ https://issues.apache.org/jira/browse/LUCENE-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959116#comment-13959116 ]
Hoss Man commented on LUCENE-5527: ---------------------------------- bq. Indeed there is! I think it would be nice to have it in Lucene, I would just like to keep this issue contained in order to make it easier to make progress. Understood -- but my point is that already in this issue: * {{LeafCollector}} is completely new, so it can have whatever methods we think it needs -- if it should have {{close()}} let's give it close. * we're discussing major changes to both the api and the functional semantics of {{Collector}} -- so if the semantics are on the table, and we think having {{close()}} is an appropriate semantic for Collector to have (in it's new context as a think that returns {{LeafCollectors}}) then lets make sure that's on the table as well. > Make the Collector API work per-segment > --------------------------------------- > > Key: LUCENE-5527 > URL: https://issues.apache.org/jira/browse/LUCENE-5527 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Adrien Grand > Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5527.patch > > > Spin-off of LUCENE-5299. > LUCENE-5229 proposes different changes, some of them being controversial, but > there is one of them that I really really like that consists in refactoring > the {{Collector}} API in order to have a different Collector per segment. > The idea is, instead of having a single Collector object that needs to be > able to take care of all segments, to have a top-level Collector: > {code} > public interface Collector { > AtomicCollector setNextReader(AtomicReaderContext context) throws > IOException; > > } > {code} > and a per-AtomicReaderContext collector: > {code} > public interface AtomicCollector { > void setScorer(Scorer scorer) throws IOException; > void collect(int doc) throws IOException; > boolean acceptsDocsOutOfOrder(); > } > {code} > I think it makes the API clearer since it is now obious {{setScorer}} and > {{acceptDocsOutOfOrder}} need to be called after {{setNextReader}} which is > otherwise unclear. > It also makes things more flexible. For example, a collector could much more > easily decide to use different strategies on different segments. In > particular, it makes the early-termination collector much cleaner since it > can return different atomic collectors implementations depending on whether > the current segment is sorted or not. > Even if we have lots of collectors all over the place, we could make it > easier to migrate by having a Collector that would implement both Collector > and AtomicCollector, return {{this}} in setNextReader and make current > concrete Collector implementations extend this class instead of directly > extending Collector. -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org