Skip to content

collective.indexing is an approach to provide an abstract framework for queuing and optimizing index operations in Plone as well as dispatching them to various backends.

Notifications You must be signed in to change notification settings

quaive/collective.indexing

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Warning

You're looking at a Quaive-local fork of collective.indexing. This is only used to maintain internal releases in the 2.1.0a series, until our upstream PRs have been properly merged and released.

Please don't push master to collective, it'll upset versions there.

Introduction

collective.indexing is an approach to provide an abstract framework for queuing and optimizing index operations in Plone as well as dispatching them to various backends. The default implementation aims to replace the standard indexing mechanism of CMF to allow index operations to be handled asynchronously in a backwards-compatible way.

Queuing these operations on a transaction level allows to get rid of redundant indexing of objects and thereby providing a substantial performance improvement. By leveraging the component architecture and Zope event system collective.indexing also makes it much easier to use backends other than or in addition to the standard portal catalog for indexing, such as dedicated search engine solutions like Solr, Xapian or Google Search Appliance. One backend implementation designed to be used with this package has already been started in the form of collective.solr.

Current Status

The implementation is considered to be ready for production. It can be installed in a Plone 4.x site to enable indexing operations to be queued, optimized and dispatched to the standard portal catalog on the Zope transaction boundary thereby improving the Plone's out-of-the-box performance.

At the moment the package requires several "monkey patches", to the mixin classes currently used to hook up indexing, i.e. CMFCatalogAware and CatalogMultiplex, the portal catalog as well as to helper methods in Plone itself. It is planned to clear these up by making the classes "pluggable" via adapterization, allowing collective.indexing to hook in in clean ways.

In conjunction with collective.solr the package also provides a working solution for integration of Solr with Plone. Based on a schema configurable at zc.buildout level indexing operations can be dispatched a Solr instance in addition or alternatively to the standard catalog. This allows for minimal and very efficient indexing of standard Plone content items based on Archetypes. Providing support for other content types is rather trivial and will be support soon.

The code was written with emphasis on minimalism, clarity and maintainability. It comes with extensive tests covering the code base at more than 95%. The package is currently in use in several production sites and considered stable.

For outstanding issues and features remaining to be implemented please see the issue tracker.

Subscriber Support

The package comes with support for queueing up and performing indexing operations via event subscribers. The idea behind this is to not rely on explicit calls as defined in CMFCatalogAware alone, but instead make it possible to phase them out eventually. As the additional indexing operations added via the subscribers are optimized away anyway, this only adds very little processing overhead.

However, even though IObjectModifiedEvent has support for partial reindexing by passing a list of descriptions/index names, this is currently not used anywhere in Plone. Unfortunately that means that partial reindex operations will be "upgraded" to full reindexes, e.g. for IContainerModifiedEvent via the notifyContainerModified helper, which is one reason why subscriber support is not enabled by default for now.

To activate please use:

[instance]
...
zcml = collective.indexing:subscribers.zcml

instead of just the package name itself, re-run buildout and restart your Plone instance.

FAQs / Troubleshooting

The following tries to address some of the known issues. Please also make sure to check the package's issue tracker and use it to report new bugs and/or discuss possible enhancements. Alternatively, feedback via the "Plone Developers" mailing-list is also most welcome.

"OFS.Uninstalled Could not import class '...' from module '...'" Warnings

Symptom

When loading your Plone site after a Zope restart, i.e. when browsing it, you're seeing warnings like:

WARNING OFS.Uninstalled Could not import class 'PortalCatalogQueueProcessor' from module 'collective.indexing.indexer'
WARNING OFS.Uninstalled Could not import class 'IndexQueueSwitch' from module 'collective.indexing.queue'
Problem
Early versions of the package used persistent local utilities, which are still present in your ZODB. These utilities have meanwhile been replaced and the old instances aren't needed anymore.
Solution
Please simply re-install the package via Plone's control panel or the quick-installer. Alternatively you can also use the ZMI "Components" tab on your site root object, typically located at http://localhost:8080/plone/manage_components, to remove the broken utilities from the XML. Search for "broken".

Credits

This code was inspired by enfold.indexing and enfold.solr by Enfold Systems as well as work done at the snowsprint'08. The TransactionManager pattern is taken from enfold.solr. Development was kindly sponsored by Elkjop.

About

collective.indexing is an approach to provide an abstract framework for queuing and optimizing index operations in Plone as well as dispatching them to various backends.

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Python 100.0%