lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2345) Make it possible to subclass SegmentReader
Date Fri, 26 Mar 2010 13:12:27 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850127#action_12850127
] 

Tim Smith commented on LUCENE-2345:
-----------------------------------

bq. I think we should only commit this only on 3.1 (new feature)? 

3.1 only of course (just posted a 3.0 patch now as that's what i'm using and i need the functionality
now)

bq. Tim, do you think the plugin model ("extension by composition") would be workable for
your use case? Ie, instead of a factory enabling subclasses of SegmentReader?

As long as the plugin model allows the same capabilities, that could work just fine and could
be the final solution for this ticket.

I mainly need the ability to add data structures to a SegmentReader that will be shared for
all SegmentReader's for a segment, and then add some extra meta information on a per instance
basis

Is there a ticket or wiki page that details the "plugin" architecture/design so i could take
a look?

However, would the plugins allow overriding specific IndexReader methods?

I still would see the need to be able to override specific methods for a SegmentReader (in
order to track statistics/provide changed/different/faster/more feature rich implementations)
I don't have a direct need for this right now, however i could envision needing this in the
future

Here's a few requirements i would pose for the plugin model (maybe they are already though
of):
* Plugins have hooks to "reopen" themselves (some plugins can be shared across all instances
of a SegmentReader)
** These reopen hooks would be called during SegmentReader.reopen()
* Plugins are initialized during "SegmentReader.get/SegmentReader.reopen"
** plugins should not have to be added after the fact, as this would not allow proper warming/initializing
of plugins inside the NRT indexing
** i assume this would need be added as some list of PluginFactories added to the IndexWriter/IndexReader.open()?
* Plugins should have a "close" method that is called in SegmentReader.close()
** This will allow proper release of any resources
* Plugins are passed an instance of the SegmentReader they are for
** Plugins should be able to access all methods on a SegmentReader
** This would effectively allow overriding a SegmentReader by having a plugin provide the
functionality instead (however only people explicitly calling the plugin would get this benefit)





> Make it possible to subclass SegmentReader
> ------------------------------------------
>
>                 Key: LUCENE-2345
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2345
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Index
>            Reporter: Tim Smith
>             Fix For: 3.1
>
>         Attachments: LUCENE-2345_3.0.patch
>
>
> I would like the ability to subclass SegmentReader for numerous reasons:
> * to capture initialization/close events
> * attach custom objects to an instance of a segment reader (caches, statistics, so on
and so forth)
> * override methods on segment reader as needed
> currently this isn't really possible
> I propose adding a SegmentReaderFactory that would allow creating custom subclasses of
SegmentReader
> default implementation would be something like:
> {code}
> public class SegmentReaderFactory {
>   public SegmentReader get(boolean readOnly) {
>     return readOnly ? new ReadOnlySegmentReader() : new SegmentReader();
>   }
>   public SegmentReader reopen(SegmentReader reader, boolean readOnly) {
>     return newSegmentReader(readOnly);
>   }
> }
> {code}
> It would then be made possible to pass a SegmentReaderFactory to IndexWriter (for pooled
readers) as well as to SegmentReader.get() (DirectoryReader.open, etc)
> I could prepare a patch if others think this has merit
> Obviously, this API would be "experimental/advanced/will change in future"

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message