Our index is now available as a service: fos_elastica.index.website. It is an instance of Elastica_Index.

If you need to have different index name from the service name, for example,
in order to have different indexes for different environments then you can
use the index_name key to change the index name. The service name will
remain the same across the environments:

Populate the types

php app/console fos:elastica:populate

This command deletes and creates the declared indexes and types.
It applies the configured mappings to the types.

This command needs providers to insert new documents in the elasticsearch types.
There are 2 ways to create providers.
If your elasticsearch type matches a Doctrine repository or a Propel query, go for the persistence automatic provider.
Or, for complete flexibility, go for manual provider.

Persistence automatic provider

If we want to index the entities from a Doctrine repository or a Propel query,
some configuration will let ElasticaBundle do it for us.

If your elasticsearch type is bound to a Doctrine entity repository or a Propel query,
you can get your entities instead of Elastica results when you perform a search.
Declare that you want a Doctrine/Propel finder in your configuration:

As well as using the finder service for a particular Doctrine/Propel entity you
can use a manager service for each driver and get a repository for an entity to search
against. This allows you to use the same service rather than the particular finder. For
example:

As well as the default repository you can create a custom repository for an entity and add
methods for particular searches. These need to extend FOS\ElasticaBundle\Repository to have
access to the finder:

Realtime, selective index update

If you use the Doctrine integration, you can let ElasticaBundle update the indexes automatically
when an object is added, updated or removed. It uses Doctrine lifecycle events.
Declare that you want to update the index in real time:

Now the index is automatically updated each time the state of the bound Doctrine repository changes.
No need to repopulate the whole "user" index when a new User is created.

You can also choose to only listen for some of the events:

persistence:
listener:
insert: true
update: false
delete: true

Propel doesn't support this feature yet.

Checking an entity method for listener

If you use listeners to update your index, you may need to validate your
entities before you index them (e.g. only index "public" entities). Typically,
you'll want the listener to be consistent with the provider's query criteria.
This may be achieved by using the is_indexable_callback config parameter:

persistence:
listener:
is_indexable_callback: "isPublic"

If is_indexable_callback is a string and the entity has a method with the
specified name, the listener will only index entities for which the method
returns true. Additionally, you may provide a service and method name pair:

In this case, the callback will be the isIndexable() method on the specified
service and the object being considered for indexing will be passed as the only
argument. This allows you to do more complex validation (e.g. ACL checks).

As you might expect, new entities will only be indexed if the callback returns
true. Additionally, modified entities will be updated or removed from the
index depending on whether the callback returns true or false, respectively.
The delete listener disregards the callback.

Propel doesn't support this feature yet.

Ignoring missing index results

By default, FOSElasticaBundle will throw an exception if the results returned from
Elasticsearch are different from the results it finds from the chosen persistence
provider. This may pose problems for a large index where updates do not occur instantly
or another process has removed the results from your persistence provider without
updating Elasticsearch.

The error you're likely to see is something like:
'Cannot find corresponding Doctrine objects for all Elastica results.'

To solve this issue, each mapped object can be configured to ignore the missing results:

persistence:
elastica_to_model_transformer:
ignore_missing: true

Advanced elasticsearch configuration

Any setting can be specified when declaring a type. For example, to enable a custom analyzer, you could write:

Overriding the Client class to suppress exceptions

By default, exceptions from the Elastica client library will propagate through
the bundle's Client class. For instance, if the elasticsearch server is offline,
issuing a request will result in an Elastica_Exception_Client being thrown.
Depending on your needs, it may be desirable to suppress these exceptions and
allow searches to fail silently.

One way to achieve this is to override the fos_elastica.client.class service
container parameter with a custom class. In the following example, we override
the Client::request() method and return the equivalent of an empty search
response if an exception occurred.

Example of Advanced Query

If you would like to perform more advanced queries, here is one example using
the snowball stemming algorithm.

It searches for Article entities using title, tags, and categoryIds.
Results must match at least one specified categoryIds, and should match the
title or tags criteria. Additionally, we define a snowball analyzer to
apply to queries against the title field.