A question was asked on the Solr Users mailing list on how to assess a comprehensive list of Solr features. It is an interesting question, as Solr is like a balloon being blown up. It is expanding in all directions. It is unlikely that one person will be able to comprehend all the features before the next release adds some extra. Solr is definitely not a slow tortoise when it comes to competing with hares. Especially when it is the tortoise that decides in which direction the goal lies.

Still, there must be a way to approach that state of knowledge, however asymptotically.  Here would be mine, which comes from the practice of writing a Solr book as well as numerous Solr training materials.

Ever started a Solr (5.x) with an example, stopped it and then could not figure out where that example actually lives? I certainly have.

This did not used to be a problem in Solr 4.x because you started the instance manually and were forced to know where your Solr home directory was (with solr.solr.home property). And they were all in the example directory out of the box anyway. But with Solr 5, we now have startup scripts, examples, and startup configurations which make things easier to get going, but may also introduce some confusion down the road.

So, this is a compilation of all the examples Solr 5.3 ships with, what configs they are using and where the startup scripts create homes for them. Plus a couple of weird related things.

Let’s start from starter configurations. Every Solr collection has one, and several examples use the same configuration.

Solr ships with three configurations, you can see the list if you run bin/solr create_core -help. Those configurations are:

Apache Solr allows to swap two cores around for non-Cloud configurations. They take each other’s name, so it is a good way to push an updated core into a production without downtime. But an interesting question is how this is achieved. Normally, core name is it’s directory name too. So, does Solr rename the directory on the filesystem too? Not really! Instead name property in the core.properties file is updated to use the name of the other core.

I presented at the Lucene/Solr Revolution 2014 in November, comparing Solr and Elasticsearch. The target audience was a technical person who wants to understand how similar (mostly Lucene) concepts are expressed in these two products. The presentation was only 30 minutes, so I could not go into the subject as deep as I initially hoped. But the room was more than full and people came up to me afterwards saying that they really liked the comparison and found it helpful.

Leanpub is a platform for publishing books that gives author control and tools beyond those available from traditional publishers. I used it to test an idea for a Solr Clients book and was able to validate its lack of traction without spending a cent.

One of the great features of Leanpub is that a book can be updated and the readers get notified of the new version. Consequently, it is sometime useful to keep the old versions around for the author and sometimes even for the readers.

This feature is not currently present in Leanpub, but we can add that with a bit of a glue from Zapier - web automation service. This is especially useful if you are using GitHub to edit your book with automatic preview and want a full end-to-end edit-preview experience without having to touch the Leanpub website.