lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <trej...@trypticon.org>
Subject Re: Specifying a Version vs. not specifying a Version
Date Mon, 01 Jun 2015 03:37:05 GMT
On Sat, May 30, 2015 at 9:33 AM, Chris Hostetter
<hossman_lucene@fucit.org> wrote:
>
> My best understanding based on what I see in the current code, is that if
> you care about backcompat:
>
>  * you must call setVersion() on any *Analyzer* instances you construct
> before using them
>  * you must *not* construct Tokenizers or TokenFilter's directly --
> instead you must use the corrisponding Factory and pass the
> LUCENE_MATCH_VERSION_PARAM to request an instance.
>
> the Analyzers and Factories are now the only things that worry about
> Version semantics, and instantiate diff classes or call diff methods on
> the objects they instantiate, as needed to "best fit" the Version you have
> specified.

Yikes.

Okay, well actually, maybe it isn't all that bad. I guess in the
unlikely event that 5.2.0 changed something in StandardFilter, the
default constructor could be deprecated and changed to delegate to
LUCENE_5_1_0 and the other constructor could be recommended, so
backwards compatibility wouldn't even break in that scenario.

I guess that the only risk would be for someone jumping straight from
something like 3.0 ~ 5.2, where it would go from being default
constructor to default constructor, but with the behaviour differing
between the two.

I hadn't even noticed somehow that the TokenFilterFactory existed now.
That thing is interesting. We have our own similar class hierarchy,
although ours might be different enough that we can't just move
across.

TX

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message