lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: per-field similarity
Date Sat, 28 Jun 2008 00:43:23 GMT

: That would require a user to subclass both IndexWriter and Searcher.

I was assuming there would be corrisponding setters and that Searcher and 
IndexWriter would maintain Maps, but that wouldn't really help in cases of 
dynamicly named fields ... you would certinaly want some sort of Factory 
(or "SimilaritySelector" like FieldSelector) so you can plugin custom 

: Since Similarity is already passed around, adding a factory method
: their seems like the easiest approach.  It's also a class, so we could
: easily add a method.

Searcher and IndexWriter are classes too, so it's just as easy to add 
setters and getters for a new SimilarityFactory on each of them as it is 
to retrofit Similarity into being a factory for itself ... and it would 
seem less confusing.

Compatibility could even be maintained by making the current setSimilarity 
method create a SimpleSimilarityFactory that allways returns the same 
Similarity.  The getSimilarity() methods on both classes could delegate to 
the factory, newer more complex Queries can use 

: An optional Query param or other context (or more than one factory
: method) was just a quick idea... may or may not ultimately make sense.

More then one method on the factory would be great ... but all the more 
reason to create a ne class instead of adding a lot of new factory methods 
on teh existing Similarity API.

: It might be a little cleaner to pass around a SimilarityFactory, but
: that ship has sailed IMO (along with many others :-)

It's not too late ... it seems really straightforward to me (but talk is 
cheap -- i haven't actually sat down and thought of potential uses cases 
and how well they would work with this type of approach).


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

View raw message