lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Lucene's default settings & back compatibility
Date Sat, 30 May 2009 10:35:02 GMT
I think the last piece that is needed is to ask on java-user what  
others think.  In order to do that, I think it needs to be boiled down  
to a couple paragraphs.


On May 29, 2009, at 11:22 PM, Shai Erera wrote:

> So ... I've this happen a lot of times (especially in my thesis  
> work) - someone raises a controversial topic, or one that touches  
> the nervous of the system, there's a flurry of activity and then it  
> dies unexpectedly, even though it feels to everyone that there's "an  
> extra mile" that should be taken in order to bring it to completion.
> And that's what I've seen in this thread. A lot has been said - lots  
> of comments, ideas, opinions. Lots of ranting and complaining. Then  
> it died ... Thank you Grant for that last "beep", I hope that was an  
> intention to resurrect it.
> So I ask - how come that we don't have a decision? Is it because  
> we're "afraid" to make a decision? (that last sentence is supposed  
> to "tease" the community, not to pass judgement)
> I'm asking because it seems like everybody pretty much agrees on  
> most of the suggestions, so why not decide "let's do X, Y and Z" and  
> change the back-compat page starting from 2.9? If people don't  
> remember the decisions, I don't mind reiterating them.
> (I also ask because I'd like to take the improvements from  
> LUCENE-1614 to TermDocs/Positions, PhrasePositions, Spans. All  
> except PhrasePositions are public interfaces and so it matters if I  
> need to go through creating abstract classes, with new names, or I  
> can change those interfaces, asking those that implemented their own  
> TermDocs to modify the code).
> Shai
> On Wed, May 27, 2009 at 10:36 PM, Grant Ingersoll  
> <> wrote:
> So, here's a real, concrete example of the need for case by case  
> back compat.  See
> 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:
> For additional commands, e-mail:

Grant Ingersoll

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:

View raw message