[ https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798936#action_12798936 ]
Robert Muir commented on SOLR-1677: ----------------------------------- bq. WTF?!?! ... now i feel like you are just messing with my head. I am really not trying to, i guess we have just put some recent work that only happens with Version >= <somethign recent> and it would be a shame if it were never used because we made this too difficult, and it simply falls back on 2.4 and works without this parameter so no one bothers. And I also can't see anyone really spending time to aggressively ensure that the example schema etc is all up to date (personally i would try to help, it is difficult though with lucene and solr so out of sync) {quote} I've never argued that the user shouldn't be allowed to change the behavior of any class away from the (hardcoded) 2.4 behavior - i've tried to be very clear that my objection was only to the new "global" default setting that would have action at a distance for all of these Version dependent classes w/o aby obvious indication what it was affect. {quote} the hardcoded 2.4 behavior is the action at a distance, because if i do not specify Version in my configuration file, then i get this very old behavior. If this is really your concern, then i have an alternative i propose. * No default anywhere, not even in the code * Version is mandatory if the thing requires it > 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.