We have a number of indexes hosted at websolr.com, for various reasons they do not allow access to the Solr administration interface.
Previously this was not a problem, but with the latest version of seach_api_solr schema-version and solr-spec-version is automatically determined by fetching some metadata from the admin interfaces. As Websolr respons with a 401 the following check in solr_connection.inc blows up
protected function checkResponse($response) {
$code = (int) $response->code;
if ($code != 200) {
if ($code >= 400 && $code != 403 && $code != 404) {
// Add details, like Solr's exception message.
$response->status_message .= $response->data;
}
throw new SearchApiException('"' . $code . '" Status: ' . $response->status_message);
}
return $response;
}
The same issue has been filed over at apachesolr: https://drupal.org/node/1956636
One "fix" would be to make it possible to disable the automatic checkking, but as I quite like that the versions are exposed in the backend, I've instead added two configuration options under the advanced server configuration to make it possible to override the schema-version and solr-spec-versions.
It might be that another approach makes more sense, but this at least fixes the issue provided that you are OK with specifying the two versions.
The patch is done against 7.x-1.x, but it applies cleanly to 1.4 as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | override-schema-and-solr-spec-2175829-6.patch | 4.63 KB | danquah |
| #4 | override-schema-and-solr-spec-2175829-4.patch | 4.65 KB | danquah |
| #4 | searchapi-solr-exception.png | 264.38 KB | danquah |
| #4 | missing-schema.png | 204.05 KB | danquah |
| #1 | override-schema-and-solr-spec-2175829.patch | 2.96 KB | danquah |
Comments
Comment #1
danquah commentedComment #2
danquah commentedComment #3
drunken monkeyThanks for posting this issue, and already providing a patch!
What do you mean, "blows up"? For me this just prints a clean error message along with the rest of the information. Really nothing dramatic, and not a bad solution I'd say.
However, not knowing the Solr version in this case is of course unfortunate, as we do use that internally to determine some settings. So having the option to override the automatic retrieval here makes of course sense and is a nice solution to the problem. I would just make it a select field, though, of 1, 3 or 4. (Maybe with "1.4" as the label for "1", and "3.x"/"4.x" for the others). We don't need the version in more detail, and a select field is much more comfortable to use.
Also, I don't see why it would make sense to also allow users to define the schema version. We don't use it internally in any way, so the only use this would have is to display the schema version they have entered right back to them. If they really want to, they can just use the server description for that.
Or am I missing something here?
In any case, giving the user the option to specify the version of Solr they are running is really a great idea, thanks again! Could you maybe re-roll the patch with my suggestions?
Comment #4
danquah commentedThank you for the input.
OK, "blows up" was a bit colorful :) I have attached an image of the configuration-page as it looked with an unpatched search_api_solr, it could be a bit prettier, on the other hand its quite clear that some error occurred.
The reason I adde the schema-name override is that the schema-version is checked for incompatibility in the following block from around line 425 in service.inc
As far as I can tell it checks to see if solr is configured with the schema.xml bundled with search_api_solr.
I just realized that what you really want is a possibility to disable the check in the situation where we can either not retrieve the schema-name (as in this case) - or the name for some reason has to have an "incompatible" value.
I have rerolled the patch with your suggestion for a drop select-field, and changed the schema-name override to be a boolean "schema-check" override instead.
Comment #5
drunken monkeyThanks for reworking your patch, looks quite good already. There are just a few minor issues left:
The default here should be
FALSE, sinceschema_check_overrideis a boolean and not a string value. Also,check_schemamight be a better name.That should definitely be wrapped in a
t()call. Also, "Determine automatically" or the like would be a better label, given the functionality.You should use single quotes where possible, as per the coding standards. In this case, they would also eliminate the need to escape the included double quotes, which is even more important.
Other than that, I'd be happy to commit this. (Even though we should probably think at some point about how to better structure this settings page – it's getting a bit messy there.)
Comment #6
danquah commentedGood points! - I have updated the patch.
And yes, the settings page could probably use some love :)
Comment #8
drunken monkeyExcellent, thanks a lot!
Made another few corrections and then committed.
Thanks again for your work!