Add flexibility for facet fields

I have to use 4 indexes only 1 of which is Drupal format. This mostly works pretty well using search_api_solr, except for a couple of small 'hacks' I have to do.

Of course I can keep patching future releases locally but wondered if these 'hacks' might be useful to anyone else. They don't seem to have any impact on my Drupal index queries and go a long way to making the search_api_solr module very useful for my non-Drupal indexes. It would be nice to be able to upgrade without patching. :)

Thank you for all your work on these modules! We have quite an eminent site coming up to launch in November and this multi-index Solr search is one of the major features!

First hack: One of my indexes has no 'id' field, it has 'identifier'. This means that the solr connection class's ping method fails. (I don't ever call ping btw, I believe it is used in the Service class).

Index: service.inc
===================================================================
--- service.inc	(revision 499)
+++ service.inc	(working copy)
@@ -94,6 +94,13 @@
       '#description' => t('The path that identifies the Solr instance to use on the server.'),
       '#default_value' => $options['path'],
     );
+    // field used in the ping query
+    $form['default_field'] = array(
+      '#type' => 'textfield',
+      '#title' => t('Solr default field'),
+      '#description' => t('The field required by any query to this server.'),
+      '#default_value' => $options['default_field'],
+    );
 
     $form['http'] = array(
       '#type' => 'fieldset',

Index: solr_connection.inc
===================================================================
--- solr_connection.inc	(revision 500)
+++ solr_connection.inc	(working copy)
@@ -40,13 +42,16 @@
       'path' => '',
       'http_user' => NULL,
       'http_pass' => NULL,
+      'default_field'=>'id',
     );
     parent::__construct($options['host'], $options['port'], $options['path']);
     if ($options['http_user'] && $options['http_pass']) {
       $this->http_auth = 'Basic ' . base64_encode($options['http_user'] . ':' . $options['http_pass']);
     }
     // Since /ping otherwise complains about missing default field.
-    $this->_pingUrl .= '?q=id:1';
+    // $this->_pingUrl.= '?q=id:1';
+    // not all servers have field 'id'
+    $this->_pingUrl .= '?q='.$options['default_field'].':1';
   }

Second 'hack' is due to my non-Drupal indexes not having the fieldname prefixes that denote type etc., e.g.

"ss_search_api_language" and it's corresponding facet field "f_ss_search_api_language"

instead I have "subjectText" and "subjectString", which means that this code ...

// String fields have their own corresponding facet fields.
if ($field[0] == 's') {
  $field = 'f_' . $field;
}

... causes my facet query to ask for f_subjectString which returns an Exception message.

The following patch deals with this problem and results in all of my facet queries, both Drupal and non-Drupal, executing without error and returning their facets.

Index: service.inc
===================================================================
--- service.inc	(revision 1570)
+++ service.inc	(working copy)
@@ -756,7 +756,7 @@
 
       foreach ($extract_facets as $delta => $info) {
         $field = $fields[$info['field']];
-        if ($field[0] == 's') {
+        if (preg_match('/^s[a-z]_/i', $field)) {
           $field = 'f_' . $field;
         }
         if (!empty($facet_fields->$field)) {
@@ -986,7 +986,7 @@
       }
       $field = $f = $fields[$info['field']];
       // String fields have their own corresponding facet fields.
-      if ($field[0] == 's') {
+      if (preg_match('/^s[a-z]_/i', $field)) {
         $field = 'f_' . $field;
       }
       // Check for the "or" operator.
@@ -1459,7 +1459,7 @@
         $facet_fields = $response->facet_counts->facet_fields;
         foreach ($facets as $delta => $info) {
           $field = $solr_fields[$info['field']];
-          if ($field[0] == 's') {
+          if (preg_match('/^s[a-z]_/i', $field)) {
             $field = 'f_' . $field;
           }
           if (!empty($facet_fields->$field)) {

If there are better suggestions I'll be happy to hear them, however we are close to launch so am going to be quite careful about too much late refactoring. :)