You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Alexandre Rafalovitch <ar...@gmail.com> on 2012/12/21 06:37:03 UTC

Why is luceneMatchVersion a compulsory field in solrconfig.xml?

Hello,

I am looking for the smallest solrconfig.xml from instructional and
tech-support point of view.

So far, I managed to get it down to this:
<?xml version="1.0" encoding="UTF-8" ?>
<config>
  <luceneMatchVersion>LUCENE_40</luceneMatchVersion>
  <requestDispatcher handleSelect="false"></requestDispatcher>
  <requestHandler name="/select"
class="solr.SearchHandler"></requestHandler>
  <requestHandler name="/update"
class="solr.UpdateRequestHandler"></requestHandler>
  <requestHandler name="/admin/" class="solr.admin.AdminHandlers" />
  <requestHandler name="/analysis/field" startup="lazy"
class="solr.FieldAnalysisRequestHandler" />
</config>

The question is, why do I need luceneMatchVersion? Removing it seems to
throw an exception. But it's presence seems so esoteric that absolute
majority of users will never change it.

Shouldn't it be by default a LUCENE_LATEST as deemed by Solr search engine
with an option to override it for those who know what they are doing?

The second concern for me is during upgrade to latest Solr engines. How am
I to know that - to take advantage of latest Lucene bug fixes - I need to
change a version. Will I get a startup warning that I am now using older
 Lucene version? Will I have to keep checking example's solrconfig.xml for
a new value?

This seems a little fragile and counter-intuitive to me.

Regards,
   Alex.

Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)

Re: Why is luceneMatchVersion a compulsory field in solrconfig.xml?

Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Fair enough. The explicit warning on LUCENE_CURRENT means that the
implementers probably thought this through better than I did.

Thanks,
   Alex.
Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)


On Fri, Dec 21, 2012 at 7:06 PM, Shawn Heisey <so...@elyograg.org> wrote:

> LUCENE_CURRENT

Re: Why is luceneMatchVersion a compulsory field in solrconfig.xml?

Posted by Shawn Heisey <so...@elyograg.org>.
On 12/20/2012 10:37 PM, Alexandre Rafalovitch wrote:
> The question is, why do I need luceneMatchVersion? Removing it seems to
> throw an exception. But it's presence seems so esoteric that absolute
> majority of users will never change it.
>
> Shouldn't it be by default a LUCENE_LATEST as deemed by Solr search engine
> with an option to override it for those who know what they are doing?
>
> The second concern for me is during upgrade to latest Solr engines. How am
> I to know that - to take advantage of latest Lucene bug fixes - I need to
> change a version. Will I get a startup warning that I am now using older
>   Lucene version? Will I have to keep checking example's solrconfig.xml for
> a new value?

The luceneMatchVersion parameter is primarily a tool to ensure 
consistent indexing and query behavior through an upgrade.  New versions 
often result in different default behavior by analyzers, tokenizers, 
etc.  If the previous behavior was not actually a bug, and probably 
sometimes even when it WAS a bug, an older luceneMatchVersion will 
result in the previous behavior.  I think it was probably made mandatory 
in order to reduce the number of surprises that a user will face if they 
just take their old config and use it unmodified in a new version.

I found something saying that if you use LUCENE_CURRENT, Solr will spit 
out the following log entry:

WARNING: You should not use LUCENE_CURRENT as luceneMatchVersion 
property: if you use this setting, and then Solr upgrades to a newer 
release of Lucene, sizable changes may happen. If precise back 
compatibility is important then you should instead explicitly specify an 
actual Lucene version.

Note that luceneMatchVersion will not affect the index format.  That 
will follow defaults for the new version or whatever postings format you 
may have explicitly configured, a feature that is available starting in 
Solr 4.0.

Thanks,
Shawn