10 Nov 2017
I have written the following statements on slack today in a more project-related manner and thought this could make a small dev-tip post as well. Here goes 💪 You basically don’t ever want to create a file called
helpers.py (you also don’t want
common.py but let’s focus on utils for now). There are a few reasons to that: 🛠 putting things into
utils.py makes it a bag full of everything from simple datetime calculations to sophisticated validators and Class mixins 🛠 utils is a nondescriptive name so nobody including you will know what has been put there in two weeks and more importantly where to look if someone has already written that util you are looking for (because they might put it in it’s proper place) 🛠 there is always a better place with a better name than utils (examples below)
How to approach the topic in an already operating project:
🛠 it’s good to move functions out from
utils.py to their corresponding
utils/proper_module.py each time you find an example and talk with your team about the whole purpose of moving that out
🛠 if something is more generic than a simple module in your Django app / python module, you can move it higher in directory structure to the more generic
utils/proper_module.py file. So generally speaking if you want utils in your project, just make it more structured. I prefer the name helpers more than utils, but no strings attached here - it’s more important to keep consistency within the project, not looking at your own personal preferences.
Some examples of moves from
🌟 a few topic related files can reside in their own directory, so form related modules (like new field types) will reside in
📖 http://deviq.com/naming-things/ 📖 https://github.com/erikras/react-redux-universal-hot-example/issues/808 📖 https://softwareengineering.stackexchange.com/a/175190
09 Mar 2016
I have spent a few days trying to translate the configs from a Solr 3.x instance to Solr 5.5.x. The process was a bit devastating and consumed a lot of time. I did a lot of googling and browsing the documentation but I haven’t found one place with all the information essential to get things going. This is a summary of what I have done and what might be helpful for others. Let’s go!
TL;DR Remove everything and use the default
solr.xml found in
$SOLR_HOME for the new version. There are multiple changes to the
solr.xml file. Solr has introduced cores autodiscovery so all
<core> definitions can be removed. More on cores autodiscovery in the next step. The server persistency flag
persistent=“(true|false)” has been deprecated and have to be removed. Cores with proper config files will be persisten by default.
Copy old core(s) configuration directories into
$SOLR_HOME. By default this will be the directory where
solr.xml resides. For each core configuration copy the old directories to the
$SOLR_HOME. The database data folder can stay the way they were in the old version, you will specify it’s folder later on. Create an empty core.properties file in the main core directory. By default solr will only autodiscover the cores which have the file present. The file has to exist and can be empty. The created core will have the same name as the directory the file is in. If you want to change it’s name or add other configuration options place them separately in each line in a simple
key=value manner. It is explained quite well in the solr documentation. This is the place you should define the data directory for each core if it is not inside the core configuration directory. E.g. config with a core name and data directory defined:
conf/solr.xml file remove all occurances of
enablePositionIncrements with arguments. The parameter has been deprecated in Solr 4 and can’t be used. If you happen to need this setting you should take a look at this thread on Solr jira. Remove all definitions of fields for older versions of Solr. The fields are usually documented with comments about consistency with older versions. I had to remove all this from my
schema.xml to get my instance working:
<fieldType name="pint" class="solr.IntField"/>
<fieldType name="plong" class="solr.LongField"/>
<fieldType name="pfloat" class="solr.FloatField"/>
<fieldType name="pdouble" class="solr.DoubleField"/>
<fieldType name="pdate" class="solr.DateField" sortMissingLast="true"/>
<fieldType name="sint" class="solr.SortableIntField" sortMissingLast="true" omitNorms="true"/>
<fieldType name="slong" class="solr.SortableLongField" sortMissingLast="true" omitNorms="true"/>
<fieldType name="sfloat" class="solr.SortableFloatField" sortMissingLast="true" omitNorms="true"/>
<fieldType name="sdouble" class="solr.SortableDoubleField" sortMissingLast="true" omitNorms="true"/>
solrconfig.xml file to the solr version you have installed. The core won’t work if the
luceneMatchVersion won’t be changed to… match the current solr version. So for me it was 5.5.0. Change directory ownership. Check if all the cores directories belong to the solr user and change the ownership with
chown -R solr: $SOLR_HOME
🚀 First run & debugging
After making all these changes run your newly created instance or restart it if it was already running and go to admin to check that your cores were loaded. If they were not loaded and you can’t seem to find any information on what has happened try loading the core manually from the admin. It should show you the errors with core initialization with the erroring files specified.
🚀 HTTP requests to the Solr server
In the code making requests to Solr you will need to remove all
ContentType definitions. Solr 5 doesn’t accept passing ContentType in GET as well as POST requests.
🎉 All set!
This is it, let me know if you had any other problems and I will happily add more information. It seems Solr is not a pleasant piece of software at times 😎