Solarium has more focus on feature quality than quantity. However, over time Solarium has gathered quite a list of features:
Complex facet queries a supported. Multiple facet types, global and per-facet options, tagging, excluding and more!
Query building API
Instead of manually creating a querystring and params you can use an API. This API also allows for easy modification of existing queries. The complete API has phpdocs to integrate with IDE features like autocompletion.
Complex update queries
Easily combine multiple add, delete, commit, optimize and/or rollback commands into a single update query. No more XML building.
In Solarium a query is represented by an object. By using standard class inheritance for these objects together with the API you effectively get query inheritance, a very powerful concept.
The plugin system plugin system allows you to customize almost any part of Solarium. It’s also used by Solarium itself for offering optional functionality, so it doesn’t get bloated.
Enabling DisMax for a select query is just a single API call or config setting. All features, including boost parameters, are supported. Edismax support is also available.
Almost all parts of Solarium can be created based on a config file. Instead of creating very complex queries with lots of API calls you can define them in a config file. The object created after loading the config file can still be modified using the API.
While very useful, the Solr Spatial functions and filters can be somewhat complex to write. Solarium offers an easy to use API for this (by means of a query helper)
Get similar documents for your search results using MoreLikeThis (MLT). Solarium offers a query API to set MLT options and a result API to easily retrieve the MLT results for a search result. The standalone MLT handler is also supported.
Get highlighted matches for field values using Highlighting (HL). Solarium offers a query API to set HL options and a result API to easily retrieve the HL results for a search result document. Per-field highlighting options are also supported.
Solr grouping (also referred to as ‘field collapse’) is supported. You can group query result on field values or queries, or even both!
Solr spellchecking is supported. This allows you to offer a ‘Did you mean’ function to search users, offering the best alternative for a missspelled queries.
Using this select query component you can get statistics for numeric fields in your index. It supports both field and facet stats.
Terms queries can for instance be used for an autocomplete feature. Solarium has built-in support to easily use terms queries.
Solarium has built-in support for using Solr’s distributed search feature (also referred to as ‘sharding’)
By using analysis you can check how you content is being analyzed, both at index and query time. Solarium supports both document and field analysis.
You can change the way you communicate with Solr by using a different client adapter. Solarium comes with a standard adapter based on streams and an optional Zend_Http adapter with extra features like keep-alive. You can easily add your own adapter.
Term and phrase escaping
Inserting (user)data into a query? With built-in term and phrase escaping you can do this safely. To make this even easier to use a special query syntax somewhat similar to SQL prepared statements is available.
Using the loadbalancing plugin you can easily use multiple Solr servers. Features include weighted backends and failover (automatically try query on other server on failure). You can also block specific querytype or a single query from load balancing, for instance to send update queries to a master Solr instance.
This plugin automatically converts big queries into POST requests, to prevent you from exceeding querystring limits in servlet containers.
Solarium handles query building for you, so you don’t need to manually build query strings. But what if you want to manually alter the query strings sent to Solr? This plugin allows just that. You can add or overwrite any GET param, and also add headers. You can do this for a single query/request or set permanent customizations for all queries.
Solarium can be used to handle all Solr interaction, but you can also decide just to use some parts. You could for instance use only the query interface to replace an existing string-based query builder and still handle the communication with Solr and result parsing yourself. This makes sense for existing solutions.
Developed using continuous integration
This is all about quality control. The complete library is covered by unittests and a Hudson-CI config is included. During development the code is constantly validated with unittests (100% coverage) and other checks such as code style. And if an error creeps in, despite the checks, a new unittest will make sure this error wil never be reintroduced.
Solarium is fully namespaced
Since version 3.0 Solarium uses namespaces. This makes it easier to use Solarium in your own code, under any alias you like.
Solarium uses the PSR-0, PSR-1 and PSR-2 standards
Solarium tries to follow these standards as much as possible. As more and more projects adopt these standards, working on many projects becomes easier.