# Haystack Settings

As a way to extend/change the default behavior within Haystack, there are several settings you can alter within your `settings.py`. This is a comprehensive list of the settings Haystack recognizes.

## `HAYSTACK_DEFAULT_OPERATOR`

Optional

This setting controls what the default behavior for chaining `SearchQuerySet` filters together is.

Valid options are:

    HAYSTACK_DEFAULT_OPERATOR = 'AND'
    HAYSTACK_DEFAULT_OPERATOR = 'OR'

Defaults to `AND`.

## `HAYSTACK_CONNECTIONS`

Required

This setting controls which backends should be available. It should be a dictionary of dictionaries resembling the following (complete) example:

    HAYSTACK_CONNECTIONS = {
        'default': {
            'ENGINE': 'haystack.backends.solr_backend.SolrEngine',
            'URL': 'http://localhost:9001/solr/default',
            'TIMEOUT': 60 * 5,
            'INCLUDE_SPELLING': True,
            'BATCH_SIZE': 100,
            'EXCLUDED_INDEXES': ['thirdpartyapp.search_indexes.BarIndex'],
        },
        'autocomplete': {
            'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine',
            'PATH': '/home/search/whoosh_index',
            'STORAGE': 'file',
            'POST_LIMIT': 128 * 1024 * 1024,
            'INCLUDE_SPELLING': True,
            'BATCH_SIZE': 100,
            'EXCLUDED_INDEXES': ['thirdpartyapp.search_indexes.BarIndex'],
        },
        'slave': {
            'ENGINE': 'xapian_backend.XapianEngine',
            'PATH': '/home/search/xapian_index',
            'INCLUDE_SPELLING': True,
            'BATCH_SIZE': 100,
            'EXCLUDED_INDEXES': ['thirdpartyapp.search_indexes.BarIndex'],
        },
        'db': {
            'ENGINE': 'haystack.backends.simple_backend.SimpleEngine',
            'EXCLUDED_INDEXES': ['thirdpartyapp.search_indexes.BarIndex'],
        }
    }

No default for this setting is provided.

The main keys (`default` & friends) are identifiers for your application. You can use them any place the API exposes `using` as a method or kwarg.

There must always be at least a `default` key within this setting.

The `ENGINE` option is required for all backends & should point to the `BaseEngine` subclass for the backend.

Additionally, each backend may have additional options it requires:

- Solr

  - `URL` - The URL to the Solr core. e.g. http://localhost:9001/solr/collection1

  - `ADMIN_URL` - The URL to the administrative functions. e.g. http://localhost:9001/solr/admin/cores

- Whoosh

  - `PATH` - The filesystem path to where the index data is located.

- Xapian

  - `PATH` - The filesystem path to where the index data is located.

The following options are optional:

- `INCLUDE_SPELLING` - Include spelling suggestions. Default is `False`

- `BATCH_SIZE` - How many records should be updated at once via the management commands. Default is `1000`.

- `TIMEOUT` - (Solr and ElasticSearch) How long to wait (in seconds) before the connection times out. Default is `10`.

- `STORAGE` - (Whoosh-only) Which storage engine to use. Accepts `file` or `ram`. Default is `file`.

- `POST_LIMIT` - (Whoosh-only) How large the file sizes can be. Default is `128 * 1024 * 1024`.

- `FLAGS` - (Xapian-only) A list of flags to use when querying the index.

- `EXCLUDED_INDEXES` - A list of strings (as Python import paths) to indexes you do NOT want included. Useful for omitting third-party things you don’t want indexed or for when you want to replace an index.

- `KWARGS` - (Solr and ElasticSearch) Any additional keyword arguments that should be passed on to the underlying client library.

- `DATE_FACET_FIELD` - (Solr-only) Support to `date_facet` on Solr >= 6.6. Olders set `date`. Default is `range`.

## `HAYSTACK_ROUTERS`

Optional

This setting controls how routing is performed to allow different backends to handle updates/deletes/reads.

An example:

    HAYSTACK_ROUTERS = ['search_routers.MasterSlaveRouter', 'haystack.routers.DefaultRouter']

Defaults to `['haystack.routers.DefaultRouter']`.

## `HAYSTACK_SIGNAL_PROCESSOR`

Optional

This setting controls what `SignalProcessor` class is used to handle Django’s signals & keep the search index up-to-date.

An example:

    HAYSTACK_SIGNAL_PROCESSOR = 'haystack.signals.RealtimeSignalProcessor'

Defaults to `'haystack.signals.BaseSignalProcessor'`.

## `HAYSTACK_DOCUMENT_FIELD`

Optional

This setting controls what fieldname Haystack relies on as the default field for searching within.

An example:

    HAYSTACK_DOCUMENT_FIELD = 'wall_o_text'

Defaults to `text`.

## `HAYSTACK_SEARCH_RESULTS_PER_PAGE`

Optional

This setting controls how many results are shown per page when using the included `SearchView` and its subclasses.

An example:

    HAYSTACK_SEARCH_RESULTS_PER_PAGE = 50

Defaults to `20`.

## `HAYSTACK_CUSTOM_HIGHLIGHTER`

Optional

This setting allows you to specify your own custom `Highlighter` implementation for use with the `{% highlight %}` template tag. It should be the full path to the class.

An example:

    HAYSTACK_CUSTOM_HIGHLIGHTER = 'myapp.utils.BorkHighlighter'

No default is provided. Haystack automatically falls back to the default implementation.

## `HAYSTACK_ITERATOR_LOAD_PER_QUERY`

Optional

This setting controls the number of results that are pulled at once when iterating through a `SearchQuerySet`. If you generally consume large portions at a time, you can bump this up for better performance.

Note

This is not used in the case of a slice on a `SearchQuerySet`, which already overrides the number of results pulled at once.

An example:

    HAYSTACK_ITERATOR_LOAD_PER_QUERY = 100

The default is 10 results at a time.

## `HAYSTACK_LIMIT_TO_REGISTERED_MODELS`

Optional

This setting allows you to control whether or not Haystack will limit the search results seen to just the models registered. It should be a boolean.

If your search index is never used for anything other than the models registered with Haystack, you can turn this off and get a small to moderate performance boost.

An example:

    HAYSTACK_LIMIT_TO_REGISTERED_MODELS = False

Default is `True`.

## `HAYSTACK_ID_FIELD`

Optional

This setting allows you to control what the unique field name used internally by Haystack is called. Rarely needed unless your field names collide with Haystack’s defaults.

An example:

    HAYSTACK_ID_FIELD = 'my_id'

Default is `id`.

## `HAYSTACK_DJANGO_CT_FIELD`

Optional

This setting allows you to control what the content type field name used internally by Haystack is called. Rarely needed unless your field names collide with Haystack’s defaults.

An example:

    HAYSTACK_DJANGO_CT_FIELD = 'my_django_ct'

Default is `django_ct`.

## `HAYSTACK_DJANGO_ID_FIELD`

Optional

This setting allows you to control what the primary key field name used internally by Haystack is called. Rarely needed unless your field names collide with Haystack’s defaults.

An example:

    HAYSTACK_DJANGO_ID_FIELD = 'my_django_id'

Default is `django_id`.

## `HAYSTACK_IDENTIFIER_METHOD`

Optional

This setting allows you to provide a custom method for `haystack.utils.get_identifier`. Useful when the default identifier pattern of <app.label>.<object_name>.<pk> isn’t suited to your needs.

An example:

    HAYSTACK_IDENTIFIER_METHOD = 'my_app.module.get_identifier'

Default is `haystack.utils.default_get_identifier`.

## `HAYSTACK_FUZZY_MIN_SIM`

Optional

This setting allows you to change the required similarity when using `fuzzy` filter.

Default is `0.5`

## `HAYSTACK_FUZZY_MAX_EXPANSIONS`

Optional

This setting allows you to change the number of terms fuzzy queries will expand to when using `fuzzy` filter.

Default is `50`