I suggested in another blog post (which I'm still writing and will link here when I'm done) that Solr could be used to drive site-wide navigation. Robert Douglas was recently quoted to me (second hand, so I can't verify the source) that the main reason to use Solr is for facets. I would add relevancy scores to that list, but that's for another post. What occurred to me one day was that facets look a lot like “traditional” navigation, only they are smarter (and better looking) than menu items or Views exposed filters. But getting solr facets on every page of your site, they way static menus are, is a bit out of the box. First, you need a Solr response available on every page load and second, you need to be able to cache and reuse that response from one request to the next. So here's what I do to accomplish this:

• Try to load a cached query. If none exists then create, execute, and cache a default one.
• Whenever the user builds a new query, cache it so that it becomes the default query for the next page load.

Here's the code, in two hooks:

hook_init()

function mymodule_init(){
  ctools_include('object-cache');
 
  /**
    * apachesolr_drupal_query() knows about the base query class. By running it first, we make sure that
    * cached query objects get unserialized properly
    */
  $query = apachesolr_drupal_query($keys, $filterstring, $solrsort, 'search/apachesolr_search');
  $cached_query = ctools_object_cache_get('mymodule', 'apachesolr_query');
  $cached_response = ctools_object_cache_get('mymodule', 'apachesolr_response');
  
  /**
    * If no cached query exists then execute an empty search. Our implementation of
    * hook_apachesolr_process_results() will take care of caching the query and response
    * for the next time around
    */
  if (!$cached_query && !$cached_response) {
    apachesolr_search_execute(NULL, NULL, NULL, 'search/apachesolr_search', $page=0);
    return;
  }
  /**
    * TODO: If we bother to check query and response independently of one another then we should also
    * be able to respond intelligently when one is absent but the other present. Why this would be the
    * case I don't know.
    */
  if ($cached_query) {
    $query = $cached_query;
    apachesolr_current_query($query);
  }
  
  if ($cached_response) {
    apachesolr_has_searched(TRUE);
    apachesolr_static_response_cache($cached_response);
  }
}

hook_apachesolr_process_results()

/**
  * Implementation of hook_apachesolr_process_results(). 
  * This is the only hook that runs after all the query altering hooks have been
  * run. Also, it only runs if the query is good (has results). So this is where
  * we choose to cache our query and response.
  */
function mymodule_apachesolr_process_results() {
  ctools_include('object-cache');
 
  $response = apachesolr_static_response_cache();
 
  $query = apachesolr_current_query();
 
  ctools_object_cache_set('mymodule', 'apachesolr_response', $response);
  ctools_object_cache_set('mymodule', 'apachesolr_query', $query);
}

hook_init() runs early in the bootstrap phase, on every request, and before any search or block hooks get invoked. So this is a good time to check for a cached query and create one if it doesn't exist. We are using ctools object cache to store the query. But we don't do the caching up front in hook_init(). Notice that we call apachesolr_search_execute() to do the query and get the response. This function will cause hook_apachesolr_process_results(), to be invoked, just the same as if this were being done as part of a normal search. By hooking into the response processing we ensure that no matter when, how, or by whom the query is getting executed, the last query sent to Solr will be in cache on the next page load. Since we are executing in hook_init(), other hooks have ample opportunity to execute new queries, which will overwrite our default one.

The code above should be made more robust before you use it in a serious deployment. We should be checking for ctools and apachesolr before we try to call their functions, for example. And no provision is made for catching GET params, in case one should want them. Also note that your default query can have filters, sorts, and keywords passed through apachesolr_search_execute(). So this doesn't have to be a bare query.