[
https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080799#comment-14080799
]
Shai Erera commented on LUCENE-5859:
------------------------------------
You don't build an index for a specific version. Rather, much like Codecs, when
you create an Analyzer you specify its runtime behavior. With Codecs, that
would be Lucene45Codec vs Lucene49Codec. With Analyzers it's
FooAnalyzer(Version.45) vs FooAnalyzer(Version.49).
Now imagine that we didn't have this Version, and you created an index with
FooAnalyzer(), which (using Hoss's example) does not use an ApostropheFilter.
Then in 4.9 this analyzer decides to add this filter into the chain, because
somebody thinks it's so useful. You upgrade your Lucene (or Solr) jar and
suddenly your app breaks. If you run tests before, maybe you're lucky to hit
the inconsistency, you ask the list and Robert tells you "this is Open Source,
grab FooAnalyzer from Lucene 4.5 and use it instead of the one we shipped".
Fine, I can bite that bullet. Not sure if others want to bite that bullet, but
I'm willing to. Because we did document that backwards break in CHANGES, and
user should really read CHANGES...
But maybe you're not that lucky, and didn't read CHANGES and suddenly months
later you spot the inconsistency (i.e. someone complains about degraded search
experience). Now copying FooAnalyzer from 4.5 and shipping that to your
customer (or deploy in your app) isn't going to solve the problem, because the
index is corrupt. Some documents have the apostrophe indexed, others don't. So
you have to rebuild your (or your customer's index). If it's a tiny index,
maybe you and I both are willing to bite the bullet. But if it's a HUGE
collection, think billions of documents, the kind that takes days or weeks to
build ... maybe I won't mind biting the bullet (hey, it's not me who needs to
re-index), but I'm pretty positive you won't want to do that. Now you email to
the list, pissed off of course, and the only thing we can tell you is "hey, you
should have read the fucking CHANGES!!".
Now back to Version, if FooAnalyzer has a ctor which takes a Version then:
* If your app always uses the Version-ctor and passes Version.45, but still
your index breaks ... then you could blame the community. You will still need
to re-index though.
* If your app always uses the no-Version ctor ... you could only blame yourself
for being "adventurous". You will still need to re-index though.
* If your app always uses the Version-ctor, and passes Version.45 and
FooAnalyzer behaves well .. then on upgrading to 4.9 you don't hit any
inconsistency. Most likely you won't even notice the change, because you don't
read the CHANGES (but that's on you, to spot improvements that were added to
your precious FooAnalyzer).
If FooAnalyzer exposes two ctors, w/ and w/o a Version, then you can make a
decision in your app if you want to care about such things or not. I.e. if your
app indexes 100K docs, and you always rebuild the index upon upgrade, cause you
anyway do it once and it's so fast that it finishes during your coffee break,
then you don't need to worry about Version. Most likely you have a
Constants.STUPID_FUCKING_USELESS_VERSION constant somewhere, and all your code
uses it, and on upgrade you just modify it from Version.45 to Version.49. But
if you index that HUGE collection, and you've been bitten once by such
stupidity of not reading CHANGES, then you decide to play it safe and above
that Constants constant you probably have a BIG WARNING about DON'T EVER CHANGE
THAT WITHOUT READING CHANGES AND RUNNING TESTS!!!.
There is another delicate point raised on the issue -- should a FooAnalyzer
*always* offer a Version ctor or not. I.e. if it's its first version (we've
just released 4.5 and it's a new analyzer), does it need to expose a Version
ctor along w/ a default ctor? Since it doesn't have any back-compat logic,
Robert claims it shouldn't because no matter what Version you pass to it, it
simply ignores it. Hack, if you pass a Version.41, before it even existed, it
might be better if it threw an AreYouSeriousException at your face. But then,
if your app uses it in 4.5 and in 4.9 it improves to add the ApostropheFilter,
you're screwed (read above). Others (like Uwe and me) think that it always
needs to have a Version ctor, alongside a no-Version one, so that if you're the
"playing it safe" guy with that scary comment above, then you can pass
Version.45 to it, then Version.46/47/48 but on upgrading to 4.9, and you pass
Version.49, your app still works as it used to.
About Solr, I don't think it impacts Solr at the moment...
> Remove Version.java completely
> ------------------------------
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own,
> we don't need to "take responsibility" for the users analysis chain for 2
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who
> don't care about back compat (e.g. just prototyping) don't have to deal with
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this
> before), i think thats bogus, and ill counter by trying to remove them.
> Either way, I'm personally not going to add any of this kind of back compat
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this
> API completely. No one else on the planet has APIs that require a mandatory
> version parameter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
