wagtail/docs/topics/search/backends.rst

135 wiersze
4.7 KiB
ReStructuredText
Czysty Zwykły widok Historia

2014-07-09 14:42:44 +00:00
.. _wagtailsearch_backends:
========
Backends
========
2014-07-09 14:42:44 +00:00
Wagtailsearch has support for multiple backends, giving you the choice between using the database for search or an external service such as Elasticsearch. The database backend is enabled by default.
2014-07-09 14:42:44 +00:00
You can configure which backend to use with the ``WAGTAILSEARCH_BACKENDS`` setting:
2014-07-09 14:42:44 +00:00
.. code-block:: python
WAGTAILSEARCH_BACKENDS = {
'default': {
'BACKEND': 'wagtail.wagtailsearch.backends.db',
}
}
.. _wagtailsearch_backends_auto_update:
``AUTO_UPDATE``
===============
2015-06-01 08:54:17 +00:00
.. versionadded:: 1.0
By default, Wagtail will automatically keep all indexes up to date. This could impact performance when editing content, especially if your index is hosted on an external service.
The ``AUTO_UPDATE`` setting allows you to disable this on a per-index basis:
.. code-block:: python
WAGTAILSEARCH_BACKENDS = {
'default': {
'BACKEND': ...,
'AUTO_UPDATE': False,
}
}
If you have disabled auto update, you must run the :ref:`update_index` command on a regular basis to keep the index in sync with the database.
2015-08-01 09:13:46 +00:00
.. _wagtailsearch_backends_atomic_rebuild:
2015-07-08 14:59:14 +00:00
``ATOMIC_REBUILD``
==================
.. versionadded:: 1.1
By default (when using the Elasticsearch backend), when the ``update_index`` command is run, Wagtail deletes the index and rebuilds it from scratch. This causes the search engine to not return results until the rebuild is complete and is also risky as you can't rollback if an error occurs.
Setting the ``ATOMIC_REBUILD`` setting to ``True`` makes Wagtail rebuild into a separate index while keep the old index active until the new one is fully built. When the rebuild is finished, the indexes are swapped atomically and the old index is deleted.
``BACKEND``
===========
Here's a list of backends that Wagtail supports out of the box.
2014-07-09 14:42:44 +00:00
2014-07-09 15:07:53 +00:00
.. _wagtailsearch_backends_database:
2015-05-29 09:48:25 +00:00
Database Backend (default)
--------------------------
2015-05-29 09:48:25 +00:00
``wagtail.wagtailsearch.backends.db``
.. versionchanged:: 1.1
Before 1.1, the full path to the backend class had to be specified: ``wagtail.wagtailsearch.backends.db.DBSearch``
2015-05-29 09:48:25 +00:00
The database backend is very basic and is intended only to be used in development and on small sites. It cannot order results by relevance, severely hampering its usefulness when searching a large collection of pages.
2015-05-29 09:48:25 +00:00
It also doesn't support:
2014-07-09 14:42:44 +00:00
2015-05-29 09:48:25 +00:00
- Searching on fields in subclasses of ``Page`` (unless the class is being searched directly)
- :ref:`wagtailsearch_indexing_callable_fields`
- Converting accented characters to ASCII
If any of these features are important to you, we recommend using Elasticsearch instead.
2014-07-09 14:42:44 +00:00
Elasticsearch Backend
---------------------
2014-07-09 14:42:44 +00:00
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
``wagtail.wagtailsearch.backends.elasticsearch`` (Elasticsearch 1.x)
``wagtail.wagtailsearch.backends.elasticsearch2`` (Elasticsearch 2.x)
.. versionchanged:: 1.1
Before 1.1, the full path to the backend class had to be specified: ``wagtail.wagtailsearch.backends.elasticsearch.ElasticSearch``
2015-05-29 09:48:25 +00:00
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
.. versionchanged:: 1.7
2015-05-29 09:48:25 +00:00
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
Support for Elasticsearch 2.x was added
2015-05-29 09:48:25 +00:00
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
Prerequisites are the `Elasticsearch`_ service itself and, via pip, the `elasticsearch-py`_ package:
2015-11-20 09:31:32 +00:00
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
.. _Elasticsearch: https://www.elastic.co/downloads/past-releases/elasticsearch-1-7-3
2014-07-09 14:42:44 +00:00
.. code-block:: sh
2014-07-09 14:42:44 +00:00
pip install elasticsearch
The backend is configured in settings:
.. code-block:: python
WAGTAILSEARCH_BACKENDS = {
'default': {
Elasticsearch 2 support (#2573) * Created Elasticsearch 2 backend * Added tests for Elasticsearch 2 backend * Split models up into different indices pages, images and documents are now in separate indices * Prefix fields of child models to prevent mapping clashes * Replaced index_analyzer with analyzer/search_analyzer index_analyzer has been removed in Elasticsearch 2.0 https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly). * Implemented new way of representing content types in search index Instead of using a long string of model names that is queried using a "prefix" query, we instead use a multi-value string field and query it using a simple "match" query. The only reason why this isn't implemented in the Elasticsearch 1.x backend yet is backwards compatibility * Added another child model of SearchTest with clashing field mapping This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail) * Added tests for get_model_root function * fixup! Added tests for get_model_root function * Docs updates for Elasticsearch 2 support Also tweak examples to use elasticsearch2 backend by default * Test against Elasticsearch 2 on travis
2016-05-06 10:23:31 +00:00
'BACKEND': 'wagtail.wagtailsearch.backends.elasticsearch2',
2014-07-09 14:42:44 +00:00
'URLS': ['http://localhost:9200'],
'INDEX': 'wagtail',
'TIMEOUT': 5,
}
}
Other than ``BACKEND``, the keys are optional and default to the values shown. In addition, any other keys are passed directly to the Elasticsearch constructor as case-sensitive keyword arguments (e.g. ``'max_retries': 1``).
2014-07-09 14:42:44 +00:00
If you prefer not to run an Elasticsearch server in development or production, there are many hosted services available, including `Bonsai`_, who offer a free account suitable for testing and development. To use Bonsai:
2014-07-09 14:42:44 +00:00
- Sign up for an account at `Bonsai`_
- Use your Bonsai dashboard to create a Cluster.
- Configure ``URLS`` in the Elasticsearch entry in ``WAGTAILSEARCH_BACKENDS`` using the Cluster URL from your Bonsai dashboard
2014-07-09 14:42:44 +00:00
- Run ``./manage.py update_index``
.. _elasticsearch-py: http://elasticsearch-py.readthedocs.org
.. _Bonsai: https://bonsai.io/signup
2014-07-09 14:42:44 +00:00
Rolling Your Own
----------------
2014-07-09 14:42:44 +00:00
Wagtail search backends implement the interface defined in ``wagtail/wagtail/wagtailsearch/backends/base.py``. At a minimum, the backend's ``search()`` method must return a collection of objects or ``model.objects.none()``. For a fully-featured search backend, examine the Elasticsearch backend code in ``elasticsearch.py``.