{"_id":"5787dcfab008c91900aae86e","version":{"_id":"56be3388be55991700c3ca10","project":"56be3387be55991700c3ca0d","__v":8,"createdAt":"2016-02-12T19:33:28.313Z","releaseDate":"2016-02-12T19:33:28.313Z","categories":["56be3389be55991700c3ca11","57646709b0a8be1900fcd0d8","5764671c89da831700590782","57646d30c176520e00ea8fe5","5764715d4f867c0e002bc8e3","57698fa2e93bfd190028815c","576c2af16c24681700c902da","5787da96b008c91900aae865"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"__v":3,"user":"5633ec9b35355017003ca3f2","category":{"_id":"56be3389be55991700c3ca11","__v":2,"pages":["56be338abe55991700c3ca13","56be34fa37d84017009de5f7"],"project":"56be3387be55991700c3ca0d","version":"56be3388be55991700c3ca10","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-12T19:33:29.389Z","from_sync":false,"order":2,"slug":"documentation","title":"Documentation"},"project":"56be3387be55991700c3ca0d","parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-07-14T18:42:02.405Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"Sometimes saving a new schema.xml can result in an error that prevents your index from being correctly configured.\n\nWhen saving a new schema.xml, we do perform some very basic validation of the XML, in order to verify that it is well-formed, and that certain assumptions that our systems make are in place. For example, we check for the presence of a `uniqueKey` field. However, as of this writing, we cannot perform any further validation of the correctness of the schema.xml until it is loaded into Solr.\n\nFor those that reason, we highly encourage that you use a development instance of Solr loaded with a subset of your production data to test your search locally before deploying changes to production. This will give you the quickest feedback and the most detailed access to all the logs you need while developing your application's schema.xml.\n\nSome Solr clients come bundled with an instance of Solr for this reason. Sunspot for Ruby on Rails is one such example.\n\nYou can also install Solr via [homebrew](http://brew.sh/) on OS X with `brew install solr`\n\nFinally, you can follow the official Solr tutorial at [http://lucene.apache.org/solr/tutorial](http://lucene.apache.org/solr/tutorial.html) which will ultimately guide you through starting a Solr server and using it for a few sample use cases.\n\nIf it's impractical for you to set up a local instance of Solr, the Websolr add-on does let you provision two indexes. You can always create a spare index to test changes and just destroy it if anything goes too wrong.\n\nWhen you find yourself at a loss and need help digging into the production server logs, definitely get in touch and let us know. We're more than happy to dig up whatever information you need from the logs to help you get things sorted out.","excerpt":"Learn why it's not best practice to test solrconfigs out in the wild, and how to do it effectively in local development.","slug":"testing-configurations-locally","type":"basic","title":"Testing configurations locally"}

Testing configurations locally

Learn why it's not best practice to test solrconfigs out in the wild, and how to do it effectively in local development.

Sometimes saving a new schema.xml can result in an error that prevents your index from being correctly configured. When saving a new schema.xml, we do perform some very basic validation of the XML, in order to verify that it is well-formed, and that certain assumptions that our systems make are in place. For example, we check for the presence of a `uniqueKey` field. However, as of this writing, we cannot perform any further validation of the correctness of the schema.xml until it is loaded into Solr. For those that reason, we highly encourage that you use a development instance of Solr loaded with a subset of your production data to test your search locally before deploying changes to production. This will give you the quickest feedback and the most detailed access to all the logs you need while developing your application's schema.xml. Some Solr clients come bundled with an instance of Solr for this reason. Sunspot for Ruby on Rails is one such example. You can also install Solr via [homebrew](http://brew.sh/) on OS X with `brew install solr` Finally, you can follow the official Solr tutorial at [http://lucene.apache.org/solr/tutorial](http://lucene.apache.org/solr/tutorial.html) which will ultimately guide you through starting a Solr server and using it for a few sample use cases. If it's impractical for you to set up a local instance of Solr, the Websolr add-on does let you provision two indexes. You can always create a spare index to test changes and just destroy it if anything goes too wrong. When you find yourself at a loss and need help digging into the production server logs, definitely get in touch and let us know. We're more than happy to dig up whatever information you need from the logs to help you get things sorted out.