Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
This is a cheat sheet and rough guide to the integration of Drupal and Apache Solr. It will contain useful functions and how to combine them, a basic layout on how the components fit together, and some DOs and DON'Ts. All of this is based on the [apachesolr]( integration, if you're using a different module th…

#Drupal & Apache Solr Integration

This is a cheat sheet and rough guide to the integration of Drupal and Apache Solr. It will contain useful functions and how to combine them, a basic layout on how the components fit together, and some DOs and DON'Ts. All of this is based on the apachesolr integration, if you're using a different module then this will probably be of no use to you.

Useful Functions

Load All Environments

Within the Apache Solr module there is support for connecting to multiple Solr instances, each the configured connections is considered an environment within the context of the Solr modules operations. When you're interacting with Solr and there is only one connection configured then you mostly do not have to be concerned with this as the module will load the default environment by itself. However you should always try to ensure that anything you construct around Solr is designed to handle the existence of multiple environments.

To find all the configured environments run the following function:

$envs = apachesolr_load_all_environments();

This will return an array that is keyed by the machine name of the respective environment. You can then cycle through the various environements and perform your required tasks. Such as creating Views data for Views integration across all configured environments.

Load Default Environment

Regardless of the number of configured Solr connections there will always be one environment that is considered the default. To find out which environment this is in your code use the following function:

$env_id = apachesolr_default_environment();

This will return a string that represents the environment ID. solr for example.

Have we just searched?

Sometimes your module will need to take different actions if a Solr search has just been run on this page. If you're dealing with facets or the FacetAPI then this is an important function. Maybe you have a dynamic feedback block that depends reacts depending on what has been searched for.

if (apachesolr_has_searched()) {
  // Do stuff!!

If we have searched, give me the solr instance.

Following on from the previous function, if we have just searched and we need some information about what query was run then we need to ask Solr to give us the solr instance object from the cache for a particular environment. You can pass different environment IDs to this function to retrieve current instances only if they have been run for the environment you're interested in.

$solr = apachesolr_current_searcher($env_id);
// You can also do the following.
$solr = apachesolr_current_searcher(apachesolr_default_environment());

When you have a Solr instance, get the response.

When you have a Solr instance you can then ask for the response object that is the result of the current query. This response object can be interrogated for result rows, facet counts, number of results, and stats if they're in use.

$solr = apachesolr_current_searcher(apachesolr_default_environment());
$response = apachesolr_static_response_cache($solr->getSearch());

What was passed to Solr in the Query?

If you have a Solr query and you would like to know what the parameters of the query were then use the following function.

$params = $solr->getParams();

This returns an array that contains the q, fq, and all the various parameters and their respective values.

Searching Solr from Code.

If you have a need to run a Solr query from within your module or from within a piece of code there might be a large temptation to instantiate a SolrBaseQuery and add all of the params and then execute the search. There are two helper functions that handle all of the boilerplate code surrounding executing a Solr query, including running all of the associated query_alter checks that would be excluded if you were to do everything yourself, leading to potentially strange results in some configurations.

$params = array(
  'q' => 'foofoo',
  'fq' => 'ss_bar:Spoon*',
  'facet' => TRUE,
  'facet.field' => array(
// An identifier for this query, usually is 'apachesolr' but is used
// to match any search blocks on the page if that is the required result.
// Leaving it as 'apachesolr' is fine for most use cases.
$name = 'apachesolr';
// This is the minimum required for a search.
$query_obj = apachesolr_drupal_query($name, $params);
// Now we have a query object instantiated and populated with our search
// parameters we can run the query.
$response_array = apachesolr_do_query($query_obj);
// This array will contain two items, one is the query that was passed to
// Solr, including any alterations. The second is the response object that
// contains all of the information provided by Solr as a result of this
// query.
// array($query, $response);

This method for searching against Solr directly from your code is preferred as it ensures that any changes in the Solr query objects do not need to be accounted for in your module, the class is correctly instantiated and populated, the query includes and alterations from the various query_alter callbacks that may exist. As well as providing the requisite error checking on behalf of Solr so that you don't have to.

thank you! very helpful

┗━━━┫$ grep -irn apachesolr_current_searcher *
(no results)

Is this a function in -dev or something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment