(Solr) Search in Drupal 8 - Part 2

Drupalcon : Further Discussion on architecture (27 Sept 2013)

This discussion is purely on what we could do with Search API to solve these issues. The previous discussion (See : https://groups.drupal.org/node/327723 ) was more about what both projects could share.

hanges.

Search API and the Apache Solr module has common Solr functionality. There are a couple of options to solve this problem.

• submodules for Search API and Core Search implementation
• We discussed this during the BOF and more detail can be see above
• dependency on Search API, optional core search integration implemented for Search API
• Search API has some architectural issues that prevent Solr from being used optimally. These issues were partly discussed in the BOF and below there are some attempts to address these.
• dependency on Search API, but just use the interfaces (or other common parts) in the base module
• This would allow us to make a generic Query interface and classes that do the conversion from Query structure to a Solr or any other system query. If both systems are able to profit from this conversion it could be beneficial for both as all of the solr specific query magic then can happen in a common part.

This discussion is purely on what we could do with Search API to solve these issues. The previous discussion (See : https://groups.drupal.org/node/327723 ) was more about what both projects could share.

Architectural Issues with views, entity types and entity_load

Search API Solr: defines "Solr index" data source/item type
This would add Solr-specific functionality and importantly not rely on entities

It should also enable search/load/display data indexed from other Drupal sites. The goal is to prevent mysql queries whenever possible when displaying data and we could enable this by indexing metadata as a document available in Solr similar as how apachesolr_multisitesearch now adds metadata in Solr so it can provide the field info to Search API. It should do a best guess on the real field with the metadata present and maybe let users select through the fields tab. So to conclude : do entity loads only when necessary (configurable, maybe) and if the data is from the same site. If the data is not from the same site we should show the rendered view mode that was added to the index while indexing.

Changes necessary in Search API/Views to solve those

• New data-source controller that views uses to fetch its information
• it becomes possible to add more flexibility in the way we show data. This data could come straight from solr or from somewhere else.
• Solves the “show external data” from Solr problem. Looks a bit like embedded Sarnia.
• Adding metadata about the drupal site and its architecture to Solr
• Field structure info no longer needs a normal API call
• Viewing/view modes/viewability check in datasource controller
• This would allow multisitesearch
• Better support for not loading entities for viewing Field API fields. Getting them from Solr when possible.
• Warning (in the solr module) users if the fields they select are not present in Solr and entity_load will happen.
• Allow multiple entity types to be selected when creating an “Index”
• so we can have a multi-entity-type search page.
• Facet problems are then solved due to the fact that multiple entity types are then indexed and facets rely on the “searcher” which is related to the “index”