lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 11:52:39 GMT
>> is littered with the likes of:
>> public static IndexReader open(final Directory directory,
>> IndexDeletionPolicy deletionPolicy) throws CorruptIndexException,
>> IOException;
> But I don't understand why is this a problem...
Doubling the number of factory methods? We have to keep old signatures.

> With the early binding approach, you wouldn't pass all plugins during
> creation; you'd pass a factory object that exposes methods like:
>  getPostingsComponent(SegmentInfo)
>  getStoredFieldsComponent(SegmentInfo)
>  getValueSourceComponent(SegmentInfo)
That basically kills the whole idea.
My initial reason for adding index plugins was to support user-written
components that have strong 1-1 binding with segments. Filter caches,
Query caches, Value caches, Sort caches, Clustering caches, whatever.
The same plugin system can also support lucene-internal components
with similarily strong binding to segments/indexes.
If you introduce that factory to create components, you hardcode
component types once again, and one can't add a new type of component
without patching Lucene.

Also, I strongly believe components should receive a reader when
binding. If they need segmentInfo - they should get it from reader, if
they need anything else and it is private - there should be a getter
for it.

> But since you seem quite convinced of its worth, maybe code up a
> simple demonstration (patch on Lucene's trunk) of what it buys us,
> where early binding would not buy us that benefit, and then we can
> iterate from there?
I'll do both and then we can compare approaches.

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

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

View raw message