>> IndexReader.java 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/Кирилл Захаренко ([email protected]) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
