lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Term pollution from binary data
Date Thu, 08 Nov 2007 19:17:55 GMT
robert engels wrote:
> I think it would be better to have IndexReaderProperties, and 
> IndexWriterProperties.

What methods would these have?

The notion of a termIndexDivisor is specific to a particular IndexReader 
implementation, so probably shouldn't be handled by a generic 
IndexReaderProperties.  This case is even stronger for things like merge 
and deletion policy-specific properties.  We'd like folks who implement 
a new policy or a new IndexReader to be able to add new properties 
without having to add new methods to IndexReaderProperties.

So if all that's in IndexReaderProperties is generic stuff like 
#getInt(String), with nothing IndexReader-specific, then why not use a 
generic class like LuceneProperties, with all specific setters and 
getters on the classes they're specific to.  Does that make sense?

> Just seems an easier API for maintenance. It is more logical, as it 
> keeps related items together.

Without more examples, I don't see this to be the case.  My goal is that 
if someone adds a new parameter for a new implementation that's not in 
Lucene's core, they should be able to add setters and getters there, 
without altering the core, keeping related items together.


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

View raw message