These tags were originally introduced in 16ecd7cca3. #339 removed the fos_elastica.client definition from config.xml, so this tag needs to be added via the DI extension class now.
While we could have used an abstract definition, its ID would likely conflict with the alias we set for the default client. Remove the abstract definition altogether and simply construct new definitions for each client. This resolves the previous issue where multiple clients would overwrite the constructor arguments of the previous definition.
Due to the naming of transformer, listener, and finder services, it's possible for index/type services to clobber the ID of another concrete or abstract service. This cannot be helped without breaking BC, but we should note it within the extension class.
This probably isn't the best way to solve my problem,
but the issue is this.
Step 1: Create a new doctrine entity for which it's `is_indexable_callback`
returns false. When doctrine flushes this entity to the database,
elastia will not index it with elastic search. (Correct)
Step 2: Update your doctrine entity and change some fields so
that `is_indexable_callback` _still_ returns false. Persist and flush
to the database.
At this point, the postUpdate listener on ElastiaBundle is called
and since the `is_indexable_callback` returns false, it believes
it needs to remove it from the elastic search index and queues it
for deletion. The deletion of course fails because it was never there
in the first place.
This solution simply ignores failures from deletions in the index.
Perhaps a better solution would be to have a smarter listener
that could determine if the entity was previously present in the
elastic search index or not, but that would require significant
refactoring.
Addresses issues discuseed in #284
Credit to @bbeaulant for simple solution. Opening a PR to
discuss more generally.
Cleaning up the description paragraph and removing extra fields and pagination from the example, since we already have pagination examples elsewhere in the README.
