There are some legacy (DNN) sites using SOLR 1.3 and I’d like to get them to SOLR 3.4. Are there any core configuration changes in the schema files that would prevent a simple transfer of the schema and re-indexing?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
There are some legacy (DNN) sites using SOLR 1.3 and I’d like to get them to SOLR 3.4. Are there any core configuration changes in the schema files that would prevent a simple transfer of the schema and re-indexing?
I think version 3.4 has the most drastic changes since that is when Solr-trunk merged into Lucene trunk making the two repos more in sync. From what I can see from the release notes you have to watch out for one primary thing. Namley the index format has changed so you definitely need to reindex.
The only other thing I could find relates to no longer ignoring contradictory settings.
I would recommend you to just upgrade and try to do a quick reindex. If nothing fails catastrophically you are most likely safe.
Including the release notes I checked and some extracts I found interesting:
1.4 release notes
3.4 release notes
The Lucene index format has changed and as a result, once you upgrade,
previous versions of Solr will no longer be able to read your indices.
In a master/slave configuration, all searchers/slaves should be upgraded
before the master. If the master were to be updated first, the older
searchers would not be able to read the new index format.
Previous versions of Solr silently allow and ignore some contradictory
properties specified in schema.xml. For example:
indexed=”false” omitNorms=”false”
indexed=”false” omitTermFreqAndPositions=”false”
Field property validation has now been fixed, to ensure that
contradictions like these now generate error messages. If users
have existing schemas that generate one of these new “conflicting
‘false’ field options for non-indexed field” error messages the
conflicting “omit*” properties can safely be removed, or changed to
“true” for consistent behavior with previous Solr versions.