[
https://issues.apache.org/jira/browse/LUCENE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196479#comment-13196479
]
Uwe Schindler edited comment on LUCENE-2858 at 1/30/12 10:56 PM:
-----------------------------------------------------------------
Here the final patch. Thanks for the good work and lots of help from Robert and
Mike.
As this patch contains heavy changes, we will commit it as soon as possible so
work can go on. It would be nice, if you would not commit anything until this
is done.
There are some minor issues open:
- DirectoryReader is final and has only static factory methods. It is not
possible to subclass it in any way. The problem is mainly Solr, as Solr
accesses directory(), IndexCommits,... and therefore cannot work on abstract
IndexReader anymore. This should be changed, by e.g. handling reopening in the
IRFactory, also versions, commits,... Currently its not possible to implement
any other IRFactory that returns something else.
- The PayloadProcessorProvider has a broken API, this should be fixed. The
current patch mimics the old behaviour, but not 100%.
- ParallelReader is now atomic. We should add a sugar wrapper method to allow
synchronized composite readers (with same segment sizes) to be aligned with
MultiReaders or wrapped by Slow.
The remaining issues will be fixed in later issues!
was (Author: thetaphi):
Here the final patch. Thanks for the good work and lots of help from Robert
and Mike.
As this patch contains heavy changes, we will commit it as soon as possible so
work can go on. It would be nice, if you would not commit anything until this
is done.
There are some minor issues open:
- Directory is final and has only static factory methods. It is not possible to
subclass it in any way. The problem is mainly Solr, as Solr accesses
directory(), IndexCommits,... and therefore cannot work on abstract IndexReader
anymore. This should be changed, by e.g. handling reopening in the IRFactory,
also versions, commits,... Currently its not possible to implement any other
IRFactory that returns something else.
- The PayloadProcessorProvider has a broken API, this should be fixed. The
current patch mimics the old behaviour, but not 100%.
- ParallelReader is now atomic. We should add a sugar wrapper method to allow
synchronized composite readers (with same segment sizes) to be aligned with
MultiReaders or wrapped by Slow.
The remaining issues will be fixed in later issues!
> 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
>
> Attachments: LUCENE-2858.patch, LUCENE-2858.patch
>
>
> 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
