Hoss,
Thank you very much for clearly delineating the difference.
Just to be clear - My intent to move to 3.1 was driven by my desire to
improve my replication performance - Deducing from your explanation, I
believe the replication/indexing related changes/bug fixes like the
following will be available to me even without specifying
"<luceneMatchVersion>LUCENE_31</luceneMatchVersion>" am I right ??
faster exact PhraseQuery; merging favors segments with deletions;
primary key lookup is faster; IndexWriter.addIndexes(Directory[]) uses
file copy instead of merging; various Directory performance
improvements; compound file is dynamically turned off for large
segments; fully deleted segments are dropped on commit; faster
snowball analyzers (in contrib); ConcurrentMergeScheduler is more
careful about setting priority of merge threads.
Ravi Kiran Bhaskar
On Tue, May 10, 2011 at 2:49 PM, Chris Hostetter
<hossman_luc...@fucit.org> wrote:
>
> : Thanks Grijesh for responding. I meant that I will use the Lucene 3.1
> : jars for indexing also from now on. My current index already has a
> : million docs indexed with solr 1.4.1 version, I read somewhere that
> : once server is upgraded to 3.1, it is said that the first commit will
> : change the indexes to 3.1 format automatically. Is this true or do I
> : have to literally reindex the million docs again ?
>
> index versioning happens on a segment basis, so once you start using Solr
> 3.1, as new docs are added and segments are merged those segments will be
> updated to the new file format -- the way to ensure that "all" segments
> are updated is to optimize your index.
>
> : >>1. Do we have to reindex all content again to use Solr 3.1 ?
>
> you should not need to, know.
>
> : >>3. Apart from deploying the new solr 3.1 war; Is it just enough to set
> : >>"<luceneMatchVersion>LUCENE_31</luceneMatchVersion>" to get all the
> : >>goodies and bug fixes of the LUCENE/SOLR 3.1 ?
>
> It's not mandatory to change the <luceneMatchVersion/> to upgrade -- if
> you do want to change the <luceneMatchVersion/> then you should reindex,
> as that change causes analyzers/query parsers to behave differently (in
> ways thta might be incompatible with how they behave previously.
>
> this change is unrelated to the index fileformat -- optimizing your index
> to force the 3.1 fileformat has no impact on how what esoteric/broken
> behavior a tokenizer might have had in the past that changed once the
> <luceneMatchVersion/> setting is updated.
>
> The purpose of <luceneMatchVersion/> is to say "i want the behavior of
> X.Y, even when it's been decided that that behavior was bad, because it's
> what matches the terms i've already indexed"
>
>
> -Hoss
