This is a follow-up of the first status update with yet more info about the upcoming Solarium 3 version.
Currently in Solarium a client instance has a single adapter and this adapter holds the Solr connection settings. This effectively means you need a client instance for each Solr server / core you want to use, or need to alter settings to switch servers. Both are not ideal. Multiple client instances introduces some overhead, especially when using plugins. You need to setup each client instance. Switching adapter settings between servers is possible but not very handy.
Using multiple Solr cores, or even multiple Solr servers is quite common so this needed to be improved. I came to the conclusion that a single client should be able to communicate with multiple servers/cores. The adapters should only handle how to communicate with the servers, and not handle server settings. So, I’ve introduced a new concept in Solarium 3: ‘endpoints’. An endpoint is basically a collection of settings that define a solr server / core: host, port, path, core and timeout.
Each endpoint is defined with a key. For each query you execute you can (optionally) supply an endpoint or endpoint key, and the query is executed using this endpoint, using the same client and adapter. The first endpoint you define is automatically used as the default endpoint. This makes use for a single endpoint easier, as you don’t need to pass it to execute queries. Of course you can always set your own default endpoint if needed.
So in Solarium 3 you will only need a single Solarium client instance, no matter how many servers / cores you use.
It’s one of those changes where you immediately notice it’s the right thing to do. In Solarium 2 the implementations of the parallel execution and loadbalancer plugins had to use quite some tricks to work correctly. When switching these plugins over to the new endpoints it was very clear this was the missing concept that made the previous implementations hard.
There are also little issues with backwards compatibility. The API and config have changed a small bit, but by making the first endpoint the default endpoint it otherwise works the same as it always did in previous versions.
Until now Solarium used ‘ducktyping’. As suggested by Igor and Joshua, using interfaces would be better. I’ve introduced the following interfaces:
In most cases there also is a base implementation of the interface that can be used to extend. But that’s entirely optional, as long as you implement the interface your object will be accepted. Also, in the various methods that use these objects checks have been added for the interface.
Hopefully this helps plugin development.
Solarium uses classmaps for querytypes and for components in the select query. These maps where quite complex, for each type multiple classes had to be registered in an array structure. For instance each querytype has a query class, requestbuilder class, responseparser class and result class. This has been simplified to a single class, the query class. This class then has methods to get any other classes needed, all required methods are defined in the interface. A similar solution is used for select query components.
It makes the classmap simpler, and allows for more flexibility in implementations.
More to follow…
The set of changes described in part 1 and this part is about the current state of development. More changes are still coming up, but they will take some time to develop. As soon as there is more news I’ll post another development update!