[ https://issues.apache.org/jira/browse/LUCENE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188076#comment-13188076 ]
Uwe Schindler commented on LUCENE-2858: --------------------------------------- I will hopefully start this weekend. I just have a schedule currently that has no slots left for that. Robert and I wanted to start a branch soon, maybe I simply do that as first step soon! > Separate SegmentReaders (and other atomic readers) from composite IndexReaders > ------------------------------------------------------------------------------ > > Key: LUCENE-2858 > URL: https://issues.apache.org/jira/browse/LUCENE-2858 > Project: Lucene - Java > Issue Type: Task > Reporter: Uwe Schindler > Assignee: Uwe Schindler > Priority: Blocker > Fix For: 4.0 > > > With current trunk, whenever you open an IndexReader on a directory you get > back a DirectoryReader which is a composite reader. The interface of > IndexReader has now lots of methods that simply throw UOE (in fact more than > 50% of all methods that are commonly used ones are unuseable now). This > confuses users and makes the API hard to understand. > This issue should split "atomic readers" from "reader collections" with a > separate API. After that, you are no longer able, to get TermsEnum without > wrapping from those composite readers. We currently have helper classes for > wrapping (SlowMultiReaderWrapper - please rename, the name is really ugly; or > Multi*), those should be retrofitted to implement the correct classes > (SlowMultiReaderWrapper would be an atomic reader but takes a composite > reader as ctor param, maybe it could also simply take a List<AtomicReader>). > In my opinion, maybe composite readers could implement some collection APIs > and also have the ReaderUtil method directly built in (possibly as a "view" > in the util.Collection sense). In general composite readers do not really > need to look like the previous IndexReaders, they could simply be a > "collection" of SegmentReaders with some functionality like reopen. > On the other side, atomic readers do not need reopen logic anymore? When a > segment changes, you need a new atomic reader? - maybe because of deletions > thats not the best idea, but we should investigate. Maybe make the whole > reopen logic simplier to use (ast least on the collection reader level). > We should decide about good names, i have no preference at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org