You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (Created) (JIRA)" <ji...@apache.org> on 2012/01/31 11:14:10 UTC
[jira] [Created] (LUCENE-3734) Allow customizing/subclassing of
DirectoryReader
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
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.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-3734) Allow customizing/subclassing of
DirectoryReader
Posted by "Uwe Schindler (Updated) (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (LUCENE-3734) Allow customizing/subclassing of
DirectoryReader
Posted by "Uwe Schindler (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-3734:
----------------------------------
Description:
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).
was: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.
> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3734) Allow customizing/subclassing of
DirectoryReader
Posted by "Jason Rutherglen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197074#comment-13197074 ]
Jason Rutherglen commented on LUCENE-3734:
------------------------------------------
The issues mentioned were brought up in LUCENE-3498 and LUCENE-3497 thus yielding a +1 from me.
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Resolved] (LUCENE-3734) Allow customizing/subclassing of
DirectoryReader
Posted by "Uwe Schindler (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler resolved LUCENE-3734.
-----------------------------------
Resolution: Fixed
Committed trunk revision: 1239043
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org