[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796136#action_12796136
]
Robert Muir commented on SOLR-1677:
-----------------------------------
{quote}
User Carl helpfully replies...
That was identified as a bug with FooTokenFilter that was fixed in Lucene
3.1, but the default behavior was left as is for backcompatibility. If you
change your <luceneAnalyzerVersionDefault/> value to 3.1 (or 3.2) you'll get
the newer/better behavior - but if you used FooTokenFilterFactory in an index
analyzer you'll need to reindex.
{quote}
User Carl isn't helpful, user Carl is an idiot.
The javadoc of Version in lucene clearly says:
{noformat}
* <p><b>WARNING</b>: When changing the version parameter
* that you supply to components in Lucene, do not simply
* change the version at search-time, but instead also adjust
* your indexing code to match, and re-index.
{noformat}
User Carl could also tell Bob that its ok to index with ArabicAnalyzer and
query with ChineseAnalyzer, this kind of stupid theoretical situation isn't any
kind of valid logical argument against having a default value for this.
> Add support for o.a.lucene.util.Version for BaseTokenizerFactory and
> BaseTokenFilterFactory
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-1677
> URL: https://issues.apache.org/jira/browse/SOLR-1677
> Project: Solr
> Issue Type: Sub-task
> Components: Schema and Analysis
> Reporter: Uwe Schindler
> Attachments: SOLR-1677.patch, SOLR-1677.patch, SOLR-1677.patch,
> SOLR-1677.patch
>
>
> Since Lucene 2.9, a lot of analyzers use a Version constant to keep backwards
> compatibility with old indexes created using older versions of Lucene. The
> most important example is StandardTokenizer, which changed its behaviour with
> posIncr and incorrect host token types in 2.4 and also in 2.9.
> In Lucene 3.0 this matchVersion ctor parameter is mandatory and in 3.1, with
> much more Unicode support, almost every Tokenizer/TokenFilter needs this
> Version parameter. In 2.9, the deprecated old ctors without Version take
> LUCENE_24 as default to mimic the old behaviour, e.g. in StandardTokenizer.
> This patch adds basic support for the Lucene Version property to the base
> factories. Subclasses then can use the luceneMatchVersion decoded enum (in
> 3.0) / Parameter (in 2.9) for constructing Tokenstreams. The code currently
> contains a helper map to decode the version strings, but in 3.0 is can be
> replaced by Version.valueOf(String), as the Version is a subclass of Java5
> enums. The default value is Version.LUCENE_24 (as this is the default for the
> no-version ctors in Lucene).
> This patch also removes unneeded conversions to CharArraySet from
> StopFilterFactory (now done by Lucene since 2.9). The generics are also fixed
> to match Lucene 3.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
