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