The Apache Solr module allows sites to connect to multiple Solr cores; the settings for each core are described as an "environment".

The current hook_views_data() implementation only allows views of the default environment, and assumes that it contains nodes.

It should instead should provide a separate Views "base table" for each environment. Patch coming in a moment.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

becw’s picture

Assigned: becw » Unassigned
Status: Active » Needs review
FileSize
4.36 KB

Here's a patch. This provides a new views base table called apachesolr__$environment_id for each environment. It leaves the existing apachesolr_node base table so that existing views are not affected.

This patch also attempts to make use of sort fields for click sorting and for sort handlers, since fields that are not specifically tokenized for sorting may yield unexpected sort orders.

becw’s picture

Title: Views of non-default Apache Solr "environments" » Views of non-default Apache Solr "environments" (patch)
becw’s picture

The patch from #1 called apachesolr_get_solr() without wrapping it in a try-catch block. Here's an updated patch that fixes this. (Related issue: #1410846: Call to apachesolr_get_solr() needs to be wrapped in try-catch (patch))

becw’s picture

I also noticed that the views query handler calls apachesolr_has_searched() without an apache solr environment id; this means that the Facet API can't tell when a search has been done with apachesolr_views, and so the facet blocks do not appear on Views pages. Here's an updated patch.

becw’s picture

... and, the query handler needs to pass in the view path (including arguments). With this change, apachesolr_views works with Facet API.

ygerasimov’s picture

Status: Needs review » Fixed

Thank you very much for the patch. I have implemented this functionality using it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Nick_vh’s picture

Status: Closed (fixed) » Needs work
+++ b/apachesolr_views.views.incundefined
@@ -26,6 +26,73 @@ function apachesolr_views_views_plugins() {
+      $solr_fields = $solr->getFields(1);

This line is bringing sites down. Please use 0.

https://issues.apache.org/jira/browse/SOLR-1931

Nick_vh’s picture

Issue summary: View changes

update wording

juampynr’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
799 bytes

The problem with this approach is that it makes it impossible to debug locally using a local Solr installation since the environment info will be picked up from the base table suffix.

How could this be editable for a developer to create a new Solr Environment that points to a local Solr installation and make the View to use it?

Attached is a patch where I am reverting to how this module used to work. It took me a long time to figure out why my local Solr was not getting the requests and I fear many people will face the same issue.

MiroslavBanov’s picture

Status: Needs review » Fixed

#8 is already fixed.

#9 is working as designed. The environment must be set when the view is created, and it can't be switched. So in order to use the local Solr environment, you have to choose the the local Solr environment, when you are creating the view. This may not always be optimal, but it is still a useful functionality, and it shouldn't be reverted. Also, it is already applied, so removing it will break existing functionality.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

MiroslavBanov’s picture

Status: Closed (fixed) » Needs work

#9 is a legitimate issue. With the patch #5 applied, the way that apachsolr_views is using solr environments is completely unintuitive. The environments should be used for switching between Test/Stage/Prod. But with the #5 patch committed in commit #7, every view will be associated with a Solr environment on creation, there is no way to change the Solr environment of an existing view at all. Changing which Solr environment is the "default" Solr environment does not change which Solr environment is used by apachesolr views.

Note also that problem related with the Solr environment is reported in other issues as well: #2491841: Apachesolr Views support for features or export.

Patch #9 reverts the change in commit #7. But commit #7 has been around for a while, and reverting it without migration is bad. Ideally, the issue should be fixed in a way that existing views will continue to work just as they did previously.