[
https://issues.apache.org/jira/browse/LUCENE-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3734:
----------------------------------
Attachment: LUCENE-3734.patch
Patch that allows to write own DirectoryReader implementations (e.g. as a
filter). It basically does the same like before. DirectoryReader is abstract
(but this time all methods are *really* abstract and a subclass (the default is
StandardDirectoryReader) *must* implement them. So if you write a
DirectoryReader, it *must* support openIfChanged and so on.
DirectoryReader also have the static open() methods that return
StandardDirectoryReader behind the scenes.
A custom DirectoryReader must provide only a minimum of directory-related
methods on top of a fixed set of AtomicReaders (unchangeable, of course). All
methods are delegated to the corresponding subreader as MultiReader does, but
things like reopening the reader and returning information about versioning is
left to the subclass. By this, a custom class can simply hook into reopen logic
or maybe emulate a ParallelDirectoryReader by using ParallelReader (with a
fake, e.g. toplevel directory). It can even filter subreaders using
FilterIndexReader.
This patch also improves type safety. getSequentialSubReaders of
DirectoryReader returns AtomicReader[], it also removes as much as possible
from the termInfosIndexDivisor (only the static open() take care anymore). It
also makes the rest of method implementations final, so subclasses can *only*
implement abstract methods and not intercept other stuff. If you want to filter
lowlevel, wrap a FilterIndexReader using MultiReader.
I think thats ready to commit!
> Allow customizing/subclassing of DirectoryReader
> ------------------------------------------------
>
> Key: LUCENE-3734
> URL: https://issues.apache.org/jira/browse/LUCENE-3734
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: core/index
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-3734.patch
>
>
> 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.
> On the other hand, it should be possible to "wrap" a DirectoryReader /
> CompositeReader to handle filtering of collection based information
> (subreaders, reopening hooks,...). This can be done by making DirectoryReader
> abstract and let DirectoryReader.open return a internal hidden class
> "StandardDirectoryReader". This is similar to the relatinship between
> IndexReader and hidden DirectoryReader in the past.
> DirectoryReader will have final implementations of most methods like getting
> document stored fields, global docFreq and other statistics, but allows
> hooking into doOpenIfChanged. Also it should not be limited to SegmentReaders
> as childs - any AtomicReader is fine. This allows users to create e.g. a
> Directory-based ParallelReader (see LUCENE-3736) that supports reopen and
> (partially commits).
--
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]
