lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: IndexReader plugins
Date Mon, 13 Apr 2009 13:14:40 GMT
On Mon, Apr 13, 2009 at 9:02 AM, Earwin Burrfoot <> wrote:

>> I think I'd lean towards only at construction.  Seems dangerous to
>> allow swap in/out at some later time.
> I have several points pro-runtime:
> 1. We have a lot of static factory methods, it's gonna be a problem
> passing plugins everywhere on creation.

"We" is who here?  Couldn't "they refactor their code to callback into
those static factory methods?

Presumably you'd pass into Lucene a "CreatesXYZComponent" instance
which given a SegmentInfo (or a public'd version of it, with
extensibility, etc) returns an XYZComponent.

> 2. public <T extends IRP> void bindPlugin(Class<? super T> type, T
> instance) is typesafer than passing Map<Class, IRP> in
> constructor.

Can you make this more concrete?  (I'm having trouble following... the

> 3. Plugins support attachment/detachment and they don't need to know
> exact reason they were attached/detached for - there should be no
> difference between closing a reader and removing plugin from it.

But what's the use case here?  Why would a SegmentReader need to
detach/attach a new XYZComponent?

And... why not simply open a new SegmentReader?  With this change,
opening a new reader can be an extremely low-cost operation since you
could share already opened XYZComponents.  A SegmentReader simply
becomes a set of components held together.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message