lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 17:30:22 GMT
Any chance on a brief summary of the current motivations for IndexReader 
plugins (now that all of this discussion has taken place)?

The original example justification was to avoid putting a ValueSource in 
the IndexReader (I guess avoiding the funky init code? valueSource = new 
CachingValueSource(this, new UninversionValueSource(this))

I never intended on keeping that bit of ugly code (it was a test way to 
get the thing inited, and since I've taken valueSource out of the 
Reader), but I guess your idea would allow me to stick my
ValueCache in using a more flexible API - 
IndexReader.bind(ValueSource.class, valueSource). I don't know how 
necessary that is for other pieces though. Now that I am trying to put 
the valueSource back in the Reader (831 still in heavy flux), this is 
looking like it could be nice for that though. But I think in flight 
binding would be wrong (we shouldn't take the view of not worrying about 
our users). But unless it makes sense to bind other things like that 
(not the built in stuff and other than ValueSource), I dont know that it 
makes sense yet.  Filter caches, Query caches, etc seem easy enough to 
implement external to Lucene just using the Reader instance? I guess it 
helps with sharing (possible merging in RAM)?

Mike appears to have driven it towards modularizing the current pieces 
in SegmentReader now. Thats not so flexible though (as a generic plugin 
framework), and it seems like a bit of a leap over the original 
proposal. The gain if we get this is possibly sharing the components and 
being able to plug in new impls (do we really want to support that, 
would it make sense based on current customization needs?)?

So Marvin has mentioned that that leads us to a bit of a hybrid 
approach, but Earwin doesn't like that?

And I don't understand how initing vs inflight destroys the whole reason 
for the API - if you don't necessarily care that its reconfigurable 
inflight, whats the problem? The static constructors are not beautiful, 
but a leaky API would be worse - I'd rather unsuspecting Lucene users 
were not hit by trains :)

Hopefully I have not muddied the water further, but I can't get a clear 
grasp on this. Happy to wait for example code, but if someone can unify 
the discussion in a bit more a succinct way, I wouldnt complain ;)






---------------------------------------------------------------------
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