Thank you both for your answers.
I really like the idea of explaining the changes for luceneMatchVersion
in more detail. Maybe this could even go into the release notes?
Thanks,
Andreas
Shawn Heisey wrote on 10.05.2013 15:27:
On 5/10/2013 5:11 AM, Jan Høydahl wrote:
Hi,
The fastest way to upgrade is to leave luceneMatchVersion as LUCENE_40. Then
you will not get any surprises wrt changed behavior for existing functionality.
but you will get all the bug fixes. You can test it out on your dev box.
I've wondered if it would be possible to create a list on the wiki of
how Solr behaves differently with each successive bump in
luceneMatchVersion. That would be very helpful in helping people with
their upgrades.
The first time Solr reads the existing index, it will be converted to 4.3
format, so keep a backup in case you wish to downgrade again, since 4.0 will
not read this index. I'm not 100% sure if this auto conversion will compressed
stored fields for you or if you need a re-index for that.
I'm not sure this is right. Solr should leave existing segments alone,
but write new segments in the new format. An optimize would be required
to upgrade the format of the whole index. Of course a full reindex
after changing luceneMatchVersion is the recommended way to go, because
that version number change might result in the indexing happening
differently.
One person on IRC had trouble with the compression in 4.2.1 not being
enabled even when deleting the entire index directory and starting over,
but the entire situation sounded like their upgrade was perhaps not
complete, and I never could figure out what was happening.
Thanks,
Shawn
