[
https://issues.apache.org/jira/browse/LUCENE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982134#action_12982134
]
Michael McCandless commented on LUCENE-2858:
--------------------------------------------
I don't think we should remove setNorm/deleteDocuments, even from the composite
reader class.
Deleting docs from IR has advantages over deleting from IW: the change is
"live" to any searches running on that IR; you get an immediate count of how
many docs were deleted; you can delete by docID.
setNorm is also useful in that it can be use to boost docs (globally), live, if
that reader is being used for searching. When/if we cutover norms -> doc
values we'll have to decide what to do about setNorm...
At a higher level, for this "strong typing of atomic vs composite IRs", we
shouldn't try to change functionality -- let's just do a rote refactoring, such
that methods that now throw UOE on IR are moved to the atomic reader only.
Separately we can think about whether existing functions should be dropped...
> 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
> 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.
-
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]
