How Does collective.solr Work

We depend on collective.indexing as a means to hook into the normal catalog machinery of Plone to detect content changes. collective.indexing before version two had some persistent data structures that frequently caused problems when removing the add-on. These problems have been fixed in version two.

collective.indexing still has to hook the catalog machinery in various evil ways, as the machinery lacks the required hooks for its use-case.

Going forward it is expected for collective.indexing to be merged into the underlying ZCatalog implementation, at which point collective.solr can use those hooks directly.

Base Functionality

  • Patches the ZCatalog
  • Some queries are faster in Solr some are not
  • Indexes and Metadata duplicated
  • Full text search with SearchableText

Transactions

Solr is not transaction-aware and does not support any kind of rollback or undo. We therefore only send data to Solr at the end of any successful request. This is done via collective.indexing, a transaction manager and an end request transaction hook.

This means you won’t see any changes done to content inside a request when doing Solr searches later on in the same request.

Querying Solr With collective.solr

ZCatalog Query:

catalog(SearchableText='Foo', portal_type='Document')

Result is a Solr Object.

Direct Solr Queries:

solr_search = solrSearchResults(
    SearchableText=SearchableText,
    spellcheck='true',
    use_solr='true',
)

You can pass Solr query params directly to Solr and force a Solr response with

use_solr='true'

Mangler

collective.solr has a mangleQuery function that translates / mangles ZCatalog query parameters to replace Zope specifics with equivalent constructs for Solr.