[
https://issues.apache.org/jira/browse/LUCENE-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3716:
----------------------------------
Description:
When implementing the parent issue, I noticed a lot of other stuff in
IndexReader thats only implemented in DirectoryReader/SegmentReader and is not
really related to IndexReader at all:
- getVersion (maybe also isCurrent) only affects DirectoryReaders, because of
the commit-stuff there is no easy way for e.g. MultiReader to implement this
- reopen/openIfChanged cannot be implemented easily by most AtomicIndexReaders,
but also CompositeIndexReader is the wrong place to define those methods
- all methods returning/opening IndexCommits
In the parant issue, I already let IndexReader.open() return DirectoryReader
and I made this class public. We should move the whole stuff (including
IR.open) to DirectoryReader. Reopening outside DirectoryReader is not really
needed.
If some people think, it should maybe stay abstract (affects only the
reopen/version stuff), there are ways for other readers to implement it, but
for sure its not specific to IR's in general. In that case I would decalre an
interface that DirectoryReader implements. Code like SearcherManager/Solr could
then instanceof the IR instance and find out if it's worth reopening/version
checking).
was:
When implementing the parent issue, I noticed a lot of other stuff in
IndexReader thats only implemented in DirectoryReader/SegmentReader and is not
really related to IndexReader at all:
- getVersion (maybe also isCurrent) only affects DirectoryReaders, because of
the commit-stuff there is no easy way for e.g. MultiReader to implement this
- reopen/openIfChanged cannot be implemented easily by most AtomicIndexReaders,
but also CompositeIndexReader is the wrong place to define those methods
In the parant issue, I already let IndexReader.open() return DirectoryReader
and I made this class public. We should move the whole stuff (including
IR.open) to DirectoryReader. Reopening outside DirectoryReader is not really
needed.
If some people think, it should maybe stay abstract (there are ways for other
readers to implement it, but for sure its not specific to IR's in general). In
that case I would decalre an interface that DirectoryReader implements. Code
like SearcherManager/Solr could then instanceof the IR instance and find out if
it's worth reopening/version checking).
> Discussion topic: Move all Commit/Version&Reopen stuff from abstract IR to
> DirectoryReader
> ------------------------------------------------------------------------------------------
>
> Key: LUCENE-3716
> URL: https://issues.apache.org/jira/browse/LUCENE-3716
> Project: Lucene - Java
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0
>
>
> When implementing the parent issue, I noticed a lot of other stuff in
> IndexReader thats only implemented in DirectoryReader/SegmentReader and is
> not really related to IndexReader at all:
> - getVersion (maybe also isCurrent) only affects DirectoryReaders, because of
> the commit-stuff there is no easy way for e.g. MultiReader to implement this
> - reopen/openIfChanged cannot be implemented easily by most
> AtomicIndexReaders, but also CompositeIndexReader is the wrong place to
> define those methods
> - all methods returning/opening IndexCommits
> In the parant issue, I already let IndexReader.open() return DirectoryReader
> and I made this class public. We should move the whole stuff (including
> IR.open) to DirectoryReader. Reopening outside DirectoryReader is not really
> needed.
> If some people think, it should maybe stay abstract (affects only the
> reopen/version stuff), there are ways for other readers to implement it, but
> for sure its not specific to IR's in general. In that case I would decalre an
> interface that DirectoryReader implements. Code like SearcherManager/Solr
> could then instanceof the IR instance and find out if it's worth
> reopening/version checking).
--
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: [email protected]
For additional commands, e-mail: [email protected]
