lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 27 May 2009 19:36:07 GMT
So, here's a real, concrete example of the need for case by case back  
compat.  See https://issues.apache.org/jira/browse/LUCENE-1662

It's completely stupid that ExtendedFieldCache even exists.   It is a  
dumb workaround for a made up problem that has nothing to do with real  
coders living in the modern age of development where IDE's make  
refactoring these types of things very cheap.  Namely, the notion that  
interfaces must never change lest every 6-9 months some minute number  
of users (I'd venture it's less than 1% of users) out there, who by  
any account are completely capable of implementing hard core Lucene  
internals (like extending FieldCache), yet are seemingly incapable of  
reading a CHANGES file with a huge disclaimer in it, have to recompile  
(GASP!) their code and put in a dummy implementation of some new  
interface method.  Yet, here we are with Yonik fixing very real  
problems that are a direct result of coding around back compat. (along  
with a mistake; it took a long time for this issue to even be  
discovered) that very much effect the usability of Lucene and the day  
to day experience of a good number of users.

In other words, the real fix for L-1662 is for ExtFieldCache to be  
folded into FieldCache and for the file to be removed, never to be  
heard from again.

The same can be said for the whole Fieldable issue, but that's a  
different day.

Ranting,
Grant

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