Last updated July 6, 2015. Created on December 22, 2011.
Edited by jmdeleon, jason1234, ZeiP, dcam. Log in to edit this page.

This document refers to the 1.1 release (in beta) of the Sarnia module. Sarnia allows a Drupal site to interact with and display external data from Solr, mainly by building views of data from Solr. This is useful for large external datasets that either aren't practical to store in Drupal or that are already indexed in Solr.

Sarnia is also the name of a town in Ontario, Canada, home of the largest photovoltaic power plant in Canada.

Table of contents

  1. Installation
  2. Generating a Solr core for testing
  3. Configuring Search API
  4. Creating Views of Solr data
  5. Advanced Solr
  6. Advanced Entities
  7. Features integration
  8. Troubleshooting


Sarnia depends on Search API, Search API Solr, and Search API Views. The full list of dependencies includes:

Sarnia depends on the latest 1.x releases of Search API and Search API Solr. The included drush makefile, sarnia.make.example, may help with downloading all of the dependencies.

After downloading the required modules, installing Sarnia will enable its dependencies. Enabling the "Views UI" module (included with Views) is also recommended.

Generating a Solr core for testing

In order to use Sarnia, you need a populated Solr core to work with. Sarnia does not care what sort of data is in the core, as long as the Solr schema specifies that some fields are stored as well as indexed. You may want to use a separate Drupal site with the ApacheSolr module and content generated using Devel Generate (a module that accompanies the Devel module) to populate a Solr core for basic testing. QA testing against your own data will better reveal any issues that relate to searching and displaying your particular data set.

For generating sample Solr data, ApacheSolr is preferred over Search API. When indexing data, Solr can be configured to index data without storing it; Search API makes the decision to index most data using Solr but to not store it (make it retrievable from Solr), while ApacheSolr stores all of the data that it indexes. In short, a Solr core generated using Search API will contain very little retrievable data, while a core generated using ApacheSolr will allow you to retrieve all properties from the core--the use case that Sarnia was built to address.

Configuring Search API

To connect your Solr core to Drupal, create a Search API server configuration.

Visit the Search API configuration section:

Admin > Configuration > Search and metadata > Search API
(path: admin/config/search/search_api)

This page lists the configured Search API servers and indexes. Normally, servers and indexes are independent, but Sarnia's purpose is to use a Search API server as a data source. Instead of the normal process of creating an index and linking it up to a server through configuration, we will create a server and then let Sarnia create and manage the index:

Search API servers correspond with Solr cores, not Solr servers. If you want to use multiple Solr cores, you will create multiple "Search API servers", even though you may have a single multi-core Solr server set up.

Add a Search API server by visiting the "Add server" link. Give the server a name:

Then select the "Sarnia Solr service" service class and fill out your Solr connection information:

Clicking "Create server" will finalize your configuration, and you will be taken to an overview of your settings:

At this point, if you were to visit the Search API overview page again, you would see your new server listed:

Instead of going back to the overview page, visit the "Sarnia" tab (highlighted in image-4.png). This page allows you to create a new entity type based on your server.

The "ID field" select box contains a list of all the Solr fields that may be suitable for use as an entity id:

unique integer values; however, Sarnia has no way to determine which fields have unique values, so this choice requires some knowledge of your Solr core. This can not be changed after creating the entity type. If you are only reading from the core and not creating data or links based on Sarnia entities, it is not destructive to delete and re-enable the Sarnia entity for a particular server. Clicking "Enable" will save your configuration:

When you save your configuration, Sarnia will create a Search API index for you. You can see this index when you visit the Search API overview page:

At this point, your Drupal site is connected to Solr and can retrieve Solr data.

Creating Views of Solr data

Visit the Views UI:

Admin > Structure > Views
(path: admin/structure/views)

Create a new View using the "Add new view" link.

In the "Show" section, select the name of the index that Sarnia created; it will be titled "[your server name] (Sarnia Index)". In the "Create a page" section, the View's "Display format" will be "Unformatted list", make sure that "Fields" is selected following the "of" (i.e. Unformatted list of Fields). The form will refresh, and you can click "Continue & edit".

In the edit page for the view you have just created, if you have not already selected "Fields", do so now:

All of the Solr data is available through a single field, named "[your server name] (Sarnia Index): Data". At the time that Sarnia was designed, the Views UI lacked the ability to filter fields, and long lists of poorly labeled fields are not usable. The Sarnia field bundles all Solr fields together into a single field with a combobox select element.

Find the "Data" field by clicking "add" in the Fields section and selecting "[your server name] (Sarnia Index): Data":

Data Views fields have a "Formatter" option:

This can be used to provide basic formatting options for a property. Most text fields will benefit from using the "Filtered text" formatter with the "Plain text" option, which will translate plain text line breaks into HTML breaks and URLs into links:

If you add filters, sorts, or advanced contextual filters (formerly known as an "argument"), you will again see "[your server name] (Sarnia Index): Data" as an option. When you select it, you can choose the Solr property to filter, sort, or use as context:

You may add multiple instances of the field, filter, sort, or contextual filter, which will let you combine and arrange your data according to various Solr properties.

Advanced Solr

Often in Solr, the same piece of data will be indexed multiple times for different purposes; some fields will not be suitable for search or display. Sarnia provides some "Solr Schema" configuration to manage these behaviors.

Naming conventions for these behaviors are not standard across Solr schemas, and fields aren't described in a way that is intelligible to Sarnia (ie, nothing in the schema.xml explicitly declares the relationship between ss_* fields and sort_* fields, even they are generally different indexes of the same data), so Sarnia assumes certain conventions when applying schema rules. For example:

  • Content is often aggregated into a single content field for use in fulltext search, so the content field is not available for display.
  • Content is often aggregated and heavily tokenized in the spell field for spelling suggestions or corrections, so the spell field is not available for display.
  • The dynamic base sort_* is used for fields that are processed as a single token for sorting. There may be a duplicate version of this field for search, so sort_* fields are not available for fulltext search.
  • Solr fields containing more than one token are not suitable for sorting, since they are essentially multi-value. Sorting is disabled on content and spell fields.
  • sort_* fields that correspond with ss_* fields are used instead of the ss_* when sorting; this allows click sorting on display fields in Views.

If you crafted your Solr schema yourself, you may want to check out the "Solr Schema" tab on your Sarnia Search API server configuration; otherwise, you probably want to stay far, far away :)

Advanced Entities

In the Search API server configuration for Sarnia servers/entities, you can "manage fields" on Sarnia entities. It is possible to add fields here, but there is no corresponding interface for editing field content; saving content has not been tested, even programmatically. Sarnia's relationship with Solr is read-only, so even if an editing interface were built out, it would not be possible to edit data stored in Solr.

Features integration

It's possible to add Sarnia's Search API server and index to a feature. However, in addition to them you also need to save the corresponding entity type. Support for this exists in the VCS version, but if you have problems with it you might want to add the entity type manually using sarnia_entity_type_save().


A few pointers on already-experienced problems.

In Views, I'm not seeing the Data field but only separate fields for each value? Should I use those?
No. For Sarnia to work properly you need to use the Data field and select the required value from its settings. If the data field doesn't work, it might be that the solr_document field hasn't been added – that happens for example when you insert the sarnia entity type directly to the database without running sarnia_entity_type_save().
Should I use the only Views base table added by Search API or should Sarnia define a separate one?
You use the one added by Search API, so the Data field should be seen there. See the previous question if it isn't.
image-1.png48.31 KB
image-2.png48.32 KB
image-3.png56.27 KB
image-4.png81.88 KB
image-5.png54.29 KB
image-6.png73.64 KB
image-7.png66.83 KB
image-8.png64.78 KB
image-10.png64.18 KB
image-10a.png61.37 KB
image-12.png97.46 KB
image-13.png85.49 KB
image-14.png113.58 KB
image-15.png79.78 KB

Looking for support? Visit the forums, or join #drupal-support in IRC.


dbolser’s picture

I've worked through this very nice guide, and everything is working more or less as expected. However, my view (page) just lists all items in the index. How do I actually pass a search term to the view (page)?

Sorry for the dumb question, and thanks for the very nice module.


dbolser’s picture

Also... (How) can I configure facets to appear on the view?

dbolser’s picture

I see an answer to this question under 'bugs', but it doesn't cover much detail... for example, my search doesn't appear to be sorted by relevance (the relevance field always reads 1).

ee1’s picture

Thanks for a great module. I am a newbie to drupal and got my custom solr data easily connected to my drupal7. However after adding a new field to my solr schema I cant get it to be reflected in the sarnia index.
The sarnia-server discoveres them after I do a refresh on the solr properties though , but not the index.
My sarnia index is not marked as read only and the cron is executed.
When I create a new server the new index gets the new fields and works OK,
this introduces alot work when the schema is update though.
I have tried using both solr 3.6.1 and 4.0 but get the same error.

ee1’s picture

Finally got this to work. I didn't realise I had to go to search api and reindex :-) Thanks for a great module!

ee1’s picture

I have not been able to get the date popup search to work on my sarnia views by using of the date module.
Is this at all possible ?

cdmo’s picture

Might work for you, might not, but it worked for me to just create a Filter Criteria of "Fulltext search" and then expose that to users. With that you should be able to search the index.


gadgetb92’s picture

I have been trying to use Sarnia for a couple of days now but without success, and I was wondering if you would know the cause of the problem.

Search API Solr 7.x-1.2

Sarnia 7.x-1.1-beta2 (+ patch @

Search API 7.x-1.8

And I have tried many new versions of Search API and Search API SOLR. And using Drupal 7. But Sarnia is not working. I have tried to create server and server was successfully created. But after creation of server its not showing the SARNIA tab on the right.

Can anybody tell me what's going wrong with my process.

And if your sarnia is working properly, which version are you using for sarnia, search API and Apache Solr.

Please HELP.
Thank you.

gadgetb92’s picture


I am trying to configure and try to use sarnia module of drupal. But, I am not getting any documentation or handbook about sarnia.

I need to know how sarnia index non- drupal data. So, anybody can help with this problem.

Search API Solr 7.x-1.2

Sarnia 7.x-1.1-beta2 (+ patch @

Search API 7.x-1.8

Need help
Thank you.

strainyy’s picture

This seems like the perfect module for pulling in external data into Drupal for display. Only issue is it's poorly supported.

So you need to play around with the versions and patches to make it work.

I'll let you know my configuration... since I went through the set up and it'll probably save somebody a lot of time.

Install these search modules:

  • Sarnia 7.x-1.1-beta2
  • Search API 7.x-1.11
  • Solr Search 7.x-1.4

Along with the other dependencies listed on this page.

Apply the following patch:
(For details on how to apply a patch check out - if you're on a mac)

You should be good to go. Having issues with the views filters now though :/

jmdeleon’s picture

The dev version (beta4) has been updated (after tracking down the previous maintainer). The patches updating the module to use the most recent Search API and Search API Solr have been applied, plus a number of other fixes over the last couple of years.

jmdeleon’s picture

I thought the comment in this blog post, saying Sarnia was "so cool I had to mention it" was a neat endorsement of this module:

jmdeleon’s picture

I recently did a presentation at Drupal Camp Ottawa 2015 introducing Sarnia. Here are the slides:

For the presentation, I built up a trivial example Solr core using Solr DataImportHandler, that reads a CSV file and builds a Solr index out of it. It uses the CSV-JDBC JDBC driver ( ) to read the CSV file, so it is also a proof of concept that any data source with a JDBC driver can be used. It can be found here:

jmdeleon’s picture

This one has some good pointers on how to work with Solr field types.

mitchelljj’s picture

Before installing Sarnia: When installing Apache Solr 5.3.0 should the Config files included within the "search_api_solr" Drupal module that the documentation says should be added to the Apache Solr server configuration be added or should just the recommended method for installation from the Apache Solr website be followed?

mitchelljj’s picture

below is the answer to my question from jmdeleon which completely answered my question:


If I'm getting what you're saying, the short answer is "No.". The intent of this module is to be able to read Apache Solr indexes (indices) that are NOT specifically indices of Drupal content, ie. indices that do not use the schema.xml and configuration in the search_api_solr module, which are used to enable Solr search over Drupal content. You do not need to use the configurations in the search_api_solr module.

The most common use case where you would use Sarnia is when you create your own Apache Solr index with its own configuration, indexed against data that is not stored in Drupal.


mitchelljj’s picture

The Search_API module has (2) additional modules plus many contributed modules which are listed below.
Can you please tell me if these below modules will also work going through Sarnia?



For the search API it includes the following:
Additional modules
At the moment, this project contains, apart from the core API module, the following extension modules:
Search views: Note: this is not needed since Sarnia already integrates with Views by itself?????
(Drupal 7 only), Correct???????

This module integrates the Search API with the Views module, allowing searches on any index to be created and viewed via Views. All of an entity's properties, as well as those of related entities (e.g. a node's author's name), are available as fields, filters and arguments for all indexed fields are available and sorts (as well as click sorts) can be created on any indexed single-valued field. Also some additional features, like linking the results to the entity, are available.
For Drupal 8, Views integration is incorporated directly into the Search API module itself, it's not necessary to enable another module.
Search facets
This module provides integration with the popular Facet API module to allow facetting on any search executed with the Search API, be it a search page, a view or any other source.
However, the feature is only supported by some backends – cf. the list of backends supporting the search_api_facets feature.

Hence, the growing number of additional contrib modules, providing additional functionality or helping users customize some aspects of the search process.
Modules providing service classes
Solr search
A backend using an Apache Solr server for indexing and searching, like the popularApache Solr Search Integration module. It uses dynamic fields for indexing arbitrary entities and boasts far superior indexing- and search-performance, better result accuracy and native facetting support.
Database search
A simple, database-based backend for indexing and searching data. It's neither very fast nor accurate, but it works out of the box and can be used for testing out the Search API capabilities (it even supports facetting), or for smaller sites (or smaller, less important indexes/searches).
Fuzzy Search
A more advanced database-based backend which also allows fuzzy matches and substring matching. No longer maintained.
Sarnia is an extension of the Solr search module which provides the capability to search and display non-Drupal data indexed in Solr.
Mongo DB backend
Uses a Mongo DB for indexing and searching. Fast and scalable, it's a great alternative to the normal database backend.
Other extension modules
Search pages
A module for creating simple search pages, not using Views or any other modules. They can be used when a view would be unnecessarily slow, or for quickly testing out functionality. They also provide search blocks for starting a search from anywhere on the site.
Multi-index searches
An extension for executing a search query on several indexes at once, for servers supporting that feature (like servers with the Solr backend).
Saved searches
Lets users create search notifications so they are notified when new results are available.
Allows to add dynamic autocompletion to fulltext key fields on search forms.
Search API attachments
An extension that helps to allow indexing of attachment (or other file) contents.
The extraction can be done using :
Apache Tika Library
The Solr built-in extractor since the version 1.3.
Acquia Search since the version 1.4.
Extended search page
This module provides a page like the default "Find content" page, but based on the Search API and therefore more flexible and richer in features.
Facet API Pretty Paths
Enables pretty paths for searches with Facet API, which is often used in combination with Search API.
Search API ranges
Adds the ability to add range facets for numeric fields to searches, with a nice ruler UI.
Search API sorts
Offers highly configurable sort blocks for all searches.
Search API context
Provides "context-sensitive" blocks for Search API.
Provides base functionality for AJAXifying search pages.
Search API Location
Allows indexing and searching of geolocation data with the Solr backend.
Search API live results
Alternative to Autocomplete that shows potential results while typing.
Search API Entity Translation
Search API Entity Translation allows you to index items in several languages when using Entity translation, as well as offering a few other tools for multilingual sites.
Search API Override
This module allows you to override Search API server settings from within settings.php – the prime use being to override servers stored in features on development and staging servers.
Search API stats
This module provides a "Top searches" block displaying popular search terms.