Please also download the start point, as with last month this is different from last month’s end point so please will all attendees download this. Thanks, see you on Wednesday evening.

I have put together a starting point for the application, please could you download this in advance. This is not the same as the end point of session one, so please can you do this even if you did attend the first part.

So the important method of the compiler pass which gets called when the container is being built is the process method which looks like this:

public function process(ContainerBuilder $container)
{
    //--
}

In this method we can work with the passed in container which has been set up with parameters and service definitions from the various configuration files.

Getting and Setting Container Parameters

Working with container parameters is straight forward using the container’s accessor methods for parameters. You can check if a parameter has been defined in the container with

$container->hasParameter($name);

You can retrieve parameters set in the container with:

$container->getParameter($name);

and set a parameter in the container with:

$container->setParameter($name, $value);

Getting and Setting Service Definitions

There are also some helpful methods of the passed in container builder for working with the service definitions.

To find out if there is a definition for a service id:

$container->hasDefinition($serviceId);

This is useful if you only want to do something if a particular definition exists. In my previous post I looked at an example from the AsseticBundle where a parameter was required only if a particular service has defined so hasDefinition() was used to check for the service definition before checking if the parameter was set. Here it is again:

class CheckCssEmbedFilterPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container)
    {
        if ($container->hasDefinition('assetic.filter.cssembed') &&
            !$container->getParameterBag()->resolveValue($container->getParameter('assetic.filter.cssembed.jar'))) {
            throw new \RuntimeException('The "assetic.filters.cssembed" configuration requires a "jar" value.');
        }
    }
}

You can retrieve a definition with

$container->getDefinition($serviceId);

or

$container->findDefinition($serviceId);

which unlike getDefinition() also resolves aliases so if the $serviceId argument is an alias you will get the underlying definition.

The service definitions themselves are objects so if you retrieve a definition with these methods and make changes to it these will be reflected in the container. If, however, you are creating a new definition then you can add it to the container using:

$container->setDefinition($id, $definition);

Working with a definition

Creating a new definition

If you need to create a new definition rather than manipulate one retrieved from then container then the definition class is Symfony\Component\DependencyInjection\Definition.

Class

First up is the class of a definition, this is the class of the object returned when the service is requested from the container.

You may want to change the class used by a definition, if for example there is functionality which can only be used if a service from another bundle exists then you may have a class which make use of that other service and one that does not. The one that does not could be used for the service and then the one with the extra functionality swapped in using a compiler pass if the other service is available.

To find out what class is set for a definition:

$definition->getClass();

and to set a different class:

$definition->setClass($class); //Fully qualified class name as string

Constructor Arguments

To get an array of the constructor arguments for a definition you can use

$definition->getArguments();

or to get a single argument by its position

$definition->getArgument($index); //e.g. $definition->getArguments(0) for the first argument

You can add a new argument to the end of the arguments array using

$definition->addArgument($argument);

The argument can be a string, an array, a service parameter by using '%paramater_name%' or a service id by using

use Symfony\Component\DependencyInjection\Reference;
 
//--
 
$definition->addArgument(new Reference('service_id'));

In a similar way you can replace an already set argument by index using:

$definition->replaceArgument($index, $argument);

You can also replace all the arguments (or set some if there are none) with an array of arguments

$definition->replaceArguments($arguments);

Method Calls

If the service you are working with uses setter injection then you can manipulate any method calls in the definitions as well.

You can get an array of all the method calls with:

$definition->getMethodCalls();

Add a method call with:

$definition->addMethodCall($method, $arguments);

Where $method is the method name and $arguments is an array of the arguments to call the method with. The arguments can be strings, arrays, parameters or service ids as with the constructor arguments.

You can also replace any existing method calls with an array of new ones with:

$definition->setMethodCalls($methodCalls);

Wrapping Up

The methods available then are the same ones that can be used to configure the container in the first place and which are shown in the Symfony2 documentation along with the XML and YAML ways you may be more familiar with. You would usually want to use config files rather than directly creating the definitions when setting the container up. In compiler passes you need to use these methods for making changes to the service definitions.

I have only looked at the more common methods of the definition object here, you can see some more available methods, by looking at the relevant docs e.g. How to Use a Factory to Create Services and looking at the PHP tab in the examples. Bear in mind the place of compiler passes in the process of building the service container though, for example, if you add a tag to a definition in a compiler pass, but the pass that looks for those tags has already run, then it will have no effect.

If there is one thing to take away from this post, it is that if you dislike writing YAML or XML configs for services then just be glad you can and you do not have to write all the definitions this way

What are Compiler Passes

The lifecycle of Symfony2 service container is roughly along these lines. The configuration is loaded from the various bundles configurations and the app level config files are processed by the Extension classes in each bundle. Various compiler passes are then run against this configuration before it is all cached to file. This cached configuration is then used on subsequent requests. To read more about the loading of config files by a bundle’s extension class and processing the configuration see my posts Symfony2: Controller as Service and Symfony2: Writing a Dependency Injection Extension Configuration.

The compilation of the configuration is itself done first using a compiler pass. Further compiler passes are then used for various tasks to optimise the configuration before it is cached. For example, private services and abstract services are removed, and aliases are resolved.

Many of these compiler passes are part of the Dependency Injection component but individual bundles can register their own compiler passes. A common use is to inject tagged services into that bundle’s services. This functionality allows for services to be defined outside of a bundles config but still be used by that bundle. The bundle is not aware of these services in its own static config and a fresh container is passed to the Extension class meaning it does not have access to any other services, so compiler passes which are executed after all the configuration has been loaded are neccessary to inject tagged services. By using a compiler pass you know that all the other service config files have been already been processed.

Creating a Compiler Pass

To create a compiler pass it needs to implements the Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface interface.

It is standard practice to put the compiler passes in the DependencyInjection/Compiler folder of a bundle. They are not automatically registered though, to add the pass to the container, override the build method of the bundle definition class:

<?php
 
namespace LimeThinking\ExampleBundle;
 
use LimeThinking\ExampleBundle\DependencyInjection\Compiler\ExamplePass;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\HttpKernel\Bundle\Bundle;
 
class ExampleBundle extends Bundle
{
    public function build(ContainerBuilder $container)
    {
        $container->addCompilerPass(new ExamplePass());
    }
}

Uses for Compiler Passes

You can implement tags for your own services to allow other people to create services to be injected into your bundle. This of course only make sense for shared bundles which are released for other people to use. For bundles only used in a single application you have full control over its config and can just inject the services in there. There is a cookbook article in the Symfony docs on writing a compiler pass that makes use of tags.

Basically the compiler gives you an opportunity to manipulate the service definitions that have been compiled. Hence this being not something needed in everyday use. In most cases the service definitions in the config can be changed.

There are other uses such as providing more complicated checks on the configuration than is possible during configuration processing. For example, the configuration builder does not provide a way of checking that a value is required only when a certain service is present. The following example from AsseticBundle shows checking if a parameter has been set in the container if a particular service has been defined:

class CheckCssEmbedFilterPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container)
    {
        if ($container->hasDefinition('assetic.filter.cssembed') &&
            !$container->getParameterBag()->resolveValue($container->getParameter('assetic.filter.cssembed.jar'))) {
            throw new \RuntimeException('The "assetic.filters.cssembed" configuration requires a "jar" value.');
        }
    }
}

In my next post on this topic I will look at how to manipulate service container definitions from within a compiler pass.

1. Symfony2: Integrating elasticsearch
2. Symfony2: improving elasticsearch results
3. Symfony2: elasticsearch custom analyzers
4. Symfony2: elasticsearch custom repositories
5. Symfony2: elasticsearch autocomplete queries

In this post I will take a quick a look at how we can create another query for the indexed site entities to provide results for an autocomplete field. I am not going to look at the actual implementation of the autocomplete box or even the formatting of the response since that will depend on the autocomplete implementation.

At the moment the sort of results we are retrieving from the search index will not be suitable for use with autocomplete. For a start, whilst we have used stemming we will not get results when searching for the first part of a word in the name. For example, if we have added a site with Lime Thinking as the name then it will not be returned for a search for L, Li, Lim etc as we will need for autocomplete.

Fortunately this is very easy to remedy with elasticsearch by making our query a text_phrase_prefix query. We can also simplify the query if we assume we are only searching on the name field. So let’s make another method in the custom repository for our new query and add the type to the query object:

<?php
 
namespace LimeThinking\ExampleBundle\SearchRepository;
 
use FOQ\ElasticaBundle\Repository;
 
class SiteRepository extends Repository
{
 
    //--
 
    public function findByPartialName($searchTerm)
    {
        $nameQuery = new \Elastica_Query_Text();
        $nameQuery->setFieldQuery('name', $searchTerm);
        $nameQuery->setFieldParam('name', 'type', 'phrase_prefix');
 
        return $this->find($nameQuery);
    }
 
}

This will now return the Lime Thinking site for searches for L, Li, Lim etc as we needed.

It is worth being aware of how this query is processed so that the results make sense. If we search for multiple words then this phrase is not split up but searched for whole. So a search for lime thi will return the Lime Thinking site but a search for lim thi will not find it. The search phrase does not need to match the start of the name though, so a search for thi will return the Lime Thinking entity.

Additionally if we were also to index a site with the name Lime Pickle then we would get both sites for lim but only Lime Thinking on a search for lime thin which differs from the search from previous posts where both would be found for a search for lime thin.

1. Symfony2: Integrating elasticsearch
2. Symfony2: improving elasticsearch results
3. Symfony2: elasticsearch custom analyzers
4. Symfony2: elasticsearch custom repositories

A new feature of the FOQElasticaSearch bundle is the provision of repositories similar to those for Doctrine queries. The first advantage of this is that instead of having to use the finder service specific to a particular entity you can use the same manager service for all mapped entities and use the entity class name to get a repository to run queries against. So using the query we have built up in the previous posts:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $sm = $this->get('foq_elastica.finder.manager');
    $searchTerm = $request->query->get('search');
 
    $nameQuery = new \Elastica_Query_Text();
    $nameQuery->setFieldQuery('name', $searchTerm);
    $nameQuery->setFieldParam('name', 'analyzer', 'snowball');
 
    $keywordsQuery = new \Elastica_Query_Text();
    $keywordsQuery->setFieldQuery('keywords', $searchTerm);
    $keywordsQuery->setFieldParam('keywords', 'analyzer', 'snowball');
 
    $urlQuery = new \Elastica_Query_Text();
    $urlQuery->setFieldQuery('url', $searchTerm);
    $urlQuery->setFieldParam('url', 'analyzer', 'url_analyzer');
 
 
    $boolQuery = new \Elastica_Query_Bool();
    $boolQuery->addShould($nameQuery);
    $boolQuery->addShould($keywordsQuery);
    $boolQuery->addShould($urlQuery);
 
    $sites = $sm->getRepository('ExampleBundle:Site')->find($boolQuery);
    return array('sites' => $sites);
}

Note that the use of the short syntax ExampleBundle:Site is only available in master, if you are using the branch compatible with 2.0.x Symfony releases then you will need to use the fully qualified class name e.g. LimeThinking\ExampleBundle\Entity\Site.

A much bigger advantage of using this functionality is that we can create a custom repository to encapsulate our query which will clean up our controller method and make it easy to reuse elsewhere. So our custom repository looks like this:

<?php
 
namespace LimeThinking\ExampleBundle\SearchRepository;
 
use FOQ\ElasticaBundle\Repository;
 
class SiteRepository extends Repository
{
 
    public function findByNameKeywordsOrUrl($searchTerm)
    {
        $nameQuery = new \Elastica_Query_Text();
        $nameQuery->setFieldQuery('name', $searchTerm);
        $nameQuery->setFieldParam('name', 'analyzer', 'snowball');
 
        $keywordsQuery = new \Elastica_Query_Text();
        $keywordsQuery->setFieldQuery('keywords', $searchTerm);
        $keywordsQuery->setFieldParam('keywords', 'analyzer', 'snowball');
 
        $urlQuery = new \Elastica_Query_Text();
        $urlQuery->setFieldQuery('url', $searchTerm);
        $urlQuery->setFieldParam('url', 'analyzer', 'url_analyzer');
 
        $boolQuery = new \Elastica_Query_Bool();
        $boolQuery->addShould($nameQuery);
        $boolQuery->addShould($keywordsQuery);
        $boolQuery->addShould($urlQuery);
 
        return $this->find($boolQuery);
    }
 
 
}

The custom repository must extend the base repository in order to be able to use the relevant finder service, which is automatically injected in. We also need to specify the custom repository class. In master this can be done using an annotation:

<?php
 
namespace LimeThinking\ExampleBundle\Entity;
 
use Doctrine\ORM\Mapping as ORM;
use FOQ\ElasticaBundle\Configuration\Search;
use Symfony\Component\Validator\Constraints as Assert;
 
/**
 * @ORM\Entity
 * @ORM\Table(name="site")
 * @ORM\HasLifecycleCallbacks()
 * @Search(repositoryClass="LimeThinking\ExampleBundle\SearchRepository\SiteRepository")
 */
 
class Site
{
//--
}

For the 2.0 branch we need to specify it in our config, which now looks like this:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            //--
            types:
                site:
                    mappings:
                        name: { analyzer: snowball }
                        keywords: { analyzer: snowball }
                        url: { analyzer: url_analyzer }
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        repository: LimeThinking\ExampleBundle\SearchRepository\SiteRepository
                        provider:
                        listener:
                        finder:

Our controller method can now be simplified to this:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $sm = $this->get('foq_elastica.finder.manager');
    $searchTerm = $request->query->get('search');
 
    $sites = $sm->getRepository('ExampleBundle:Site')
                ->findByNameKeywordsOrUrl($searchTerm);
    return array('sites' => $sites);
}

The controller method is now much cleaner with the implementation of the query moved to the repository, the query can now also easily be reused elsewhere.

One thing we did not do last time was indexing the url field of the Site entity. The reason for this is that if you index urls and email addresses using the default settings they will not be split up for indexing, meaning that you cannot search on part of them. For example if we have index http://www.limethinking.co.uk then a search for limethinking will not return the indexed document.

The reason for this is the way that the strings are analyzed to decide how to index them. An analyzer is a combination of a tokenizer and filters. The tokenizer decides how to split up the string to be indexed into individual tokens, the filters are then applied to the tokens before they are indexed. The default Standard Analyzer uses the Standard Tokenizer which, using language specific rules, splits up the string using whitespace and punctuation. It has the Lowercase Token filter, which lower cases the token to avoid search being case dependant, the Stop Token filter, which removes a specified set of words so that words like and, or etc., are not indexed and the Standard Token filter.

Unfortunately for us this does not work very well for the urls we want to index because the standard tokenizer does not split on dots followed by whitespace, so urls are not split up but indexed whole. Fortunately for us it is easy to change the analyzer used in the config:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            client: default
            settings:
                index:
                    analysis:
                        analyzer:
                            url_analyzer:
                                type: custom
                                tokenizer: lowercase
                                filter: ["stop", "url_stop"]
                        filter:
                            url_stop:
                                type: "stop"
                                stopwords: ["http", "https"]
 
            types:
                site:
                    mappings:
                        name: { analyzer: snowball }
                        keywords: { analyzer: snowball }
                        url: { analyzer: url_analyzer }
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        provider:
                        listener:
                        finder:

So we are defining a custom analyzer under the settings section, using the name url_analyzer, under the site type we have added url to the mappings, specifying it should use this analyzer. The analyzer uses the Lowercase Tokenizer which splits on any non letter symbol as well as lower casing the resulting tokens. We are also using a couple of filters with this, a custom stop filter which removes http and https so they are not matched in searches as well as the standard stop filter. By removing http and https from the index for urls we can still get meaningful results if we search for these terms and have added sites with http or https in the title.

We now need to add searching the url field to our query from the previous post:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $finder = $this->get('foq_elastica.finder.bookmarks.site');
    $searchTerm = $request->query->get('search');
 
    $nameQuery = new \Elastica_Query_Text();
    $nameQuery->setFieldQuery('name', $searchTerm);
    $nameQuery->setFieldParam('name', 'analyzer', 'snowball');
 
    $keywordsQuery = new \Elastica_Query_Text();
    $keywordsQuery->setFieldQuery('keywords', $searchTerm);
    $keywordsQuery->setFieldParam('keywords', 'analyzer', 'snowball');
 
    $urlQuery = new \Elastica_Query_Text();
    $urlQuery->setFieldQuery('url', $searchTerm);
    $urlQuery->setFieldParam('url', 'analyzer', 'url_analyzer');
 
 
    $boolQuery = new \Elastica_Query_Bool();
    $boolQuery->addShould($nameQuery);
    $boolQuery->addShould($keywordsQuery);
    $boolQuery->addShould($urlQuery);
 
    $sites = $finder->find($boolQuery);
    return array('sites' => $sites);
}

This adds another Text query searching the url field using the custom url_analyzer. Now all three fields of the Site entity are being searched on.

We can improve the indexing of the name and keywords by switching to a different analyzer. Currently we are only going to find whole word matches, for example, if we index Lime Thinking as a site name then it will be found by a search for thinking, but not think or thinks. We can change this by instead using the snowball analyzer, this is a built in analyzer which is the same as the standard analyzer but with the edition of the snowball filter which stems the tokens. This means that words are indexed as their stems, so thinking will be indexed as think. We can then find it with searches for words such as think, thinks and thinkings. I will have a more detailed look at analyzers and filters in a future post.

We just need to make a small config change to start using this analyzer for indexing:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            client: default
            types:
                site:
                    mappings:
                        name: { analyzer: snowball }
                        keywords: { analyzer: snowball }
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        provider:
                        listener:
                        finder:

We need to make some further changes though to get the benefits of this. We also need to make sure that the search terms are analyzed with the same analyzer as the indexed field. If this does not happen we will only get matches if we search for the stemmed token e.g. think will find Lime Thinking but thinking will not. Our simple query does not specify which field we are searching, this means its searches the built in _all field which, unsurprisingly, contains all the fields. This means we cannot use different analyzers for searching different fields. We are going to want to add the url at some point using a different analyzer so we need to specify each field we want to search separately.

So we now need to split up our query into several parts. For this we need to use Elastica’s query builder objects. To search on a specific field we can use a Text query, so to search on the name field we use:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $finder = $this->get('foq_elastica.finder.bookmarks.site');
    $searchTerm = $request->query->get('search');
 
    $nameQuery = new \Elastica_Query_Text();
    $nameQuery->setFieldQuery('name', $searchTerm);
 
    $sites = $finder->find($nameQuery);
    return array('sites' => $sites);
}

Notice that we pass the query object into the same method on the finder as before, this method accepts both simple search strings as well as queries built through objects. According to the elasticsearch documentation the analyzer will default to the field specific analyzer or the default one, to me this suggests that the above query will automatically use the analyzer set for the field. However this does not work for me, fortunately it easy to specify the analyzer to use for the field:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $finder = $this->get('foq_elastica.finder.bookmarks.site');
    $searchTerm = $request->query->get('search');
 
    $nameQuery = new \Elastica_Query_Text();
    $nameQuery->setFieldQuery('name', $searchTerm);
    $nameQuery->setFieldParam('name', 'analyzer', 'snowball');
 
    $sites = $finder->find($nameQuery);
    return array('sites' => $sites);
}

Our current query will of course only search the name field, what we want to do is search the name field and the keywords field using the snowball analyzer. This is done by creating another query as above for the keywords field and then using a boolean query to combine the two individual queries into one query:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $finder = $this->get('foq_elastica.finder.bookmarks.site');
    $searchTerm = $request->query->get('search');
 
    $nameQuery = new \Elastica_Query_Text();
    $nameQuery->setFieldQuery('name', $searchTerm);
    $nameQuery->setFieldParam('name', 'analyzer', 'snowball');
 
    $keywordsQuery = new \Elastica_Query_Text();
    $keywordsQuery->setFieldQuery('keywords', $searchTerm);
    $keywordsQuery->setFieldParam('keywords', 'analyzer', 'snowball');
 
    $boolQuery = new \Elastica_Query_Bool();
    $boolQuery->addShould($nameQuery);
    $boolQuery->addShould($keywordsQuery);
 
    $sites = $finder->find($boolQuery);
    return array('sites' => $sites);
}

Whilst this looks complicate each constituent part is simple and this is a good way to build more complicated queries.

A really helpful recent inclusion to the bundle is logging to the web profiler toolbar so you can see the parsed JSON query that is sent to elasticsearch. The combined query from above looks like this:

Method: GET
{ query: { bool: { should: [{ text: { name: { query: thinking, analyzer: snowball } } }, { text: { keywords: { query: thinking, analyzer: snowball } } }] } } }
Time: 8.19 ms

We have seen Text query and Boolean query here, these are just a few of the available query types. There is more information on each in the elasticsearch documentation. There is little in the way of documentation for the Elastica objects for creating these query types but the test suite provides quite a lot of example of putting them to use.

Elasticsearch is built on top of Lucene and indexes data as JSON documents in a similar way to the way MongoDB stores data. This means as with Mongo that it is schemaless and creates fields on the fly. It is queried over HTTP using queries which are themselves defined in JSON. I am not going to go into details about using elasticsearch in this way, there is plenty of information in its online documentation.

Reading through the documentation makes it look as though there is a steep learning curve to getting started with elasticsearch. What I want to do is look at how you can avoid having to deal with issuing JSON queries over HTTP from a Symfony2 app and actually get started using elasticsearch in a very simple way. This is possible by using Elastica, a PHP library which abstracts the details of the queries, along with the FOQElasticaBundle which integrates Elastica into Symfony2 applications. This is not just a basic wrapper though to make Elastica into a Symfony2 service, the integration with Doctrine to make indexing of ORM entities or ODM documents is fantastic and what I am going to look at here.

To get started you need to install elasticsearch itself, as well as installing Elastica and the FOQElasticaBundle in the usual way.

As an example of how easy the integration is I will look at a very basic application for bookmarking sites and searching for them. For simplicity’s sake we are just going to have a single entity to model each site, it is just a name, the URL and some keywords stored as a comma separated list. So here it is as a Doctrine entity class:

<?php
 
namespace LimeThinking\ExampleBundle\Entity;
 
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;
 
/**
 * @ORM\Entity
 * @ORM\Table(name="site")
 */
class Site
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;
 
    /**
     * @ORM\Column(type="string", length=255)
     * @Assert\NotBlank()
     * @Assert\MaxLength(255)
     */
    private $name;
 
    /**
     * @ORM\Column(type="string", length=255)
     * @Assert\NotBlank()
     * @Assert\Url()
     * @Assert\MaxLength(255)
     */
    private $url;
 
    /**
     * @ORM\Column(type="string", length=255)
     * @Assert\MaxLength(255)
     */
    private $keywords;
 
    public function getId()
    {
        return $this->id;
    }
 
    public function setName($name)
    {
        $this->name = $name;
    }
 
    public function getName()
    {
        return $this->name;
    }
 
    public function setUrl($url)
    {
        $this->url = $url;
    }
 
    public function getUrl()
    {
        return $this->url;
    }
 
    public function setKeywords($keywords)
    {
        $this->keywords = $keywords;
    }
 
    public function getKeywords()
    {
        return $this->keywords;
    }
 
}

We can then set up the bundle to index the fields of our entity. By choosing to use the integration with doctrine we can make this very simple:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            client: default
            types:
                site:
                    mappings:
                        name:
                        keywords:
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        provider:

Whilst there are quite a few settings here it is fairly straight forward. The client just sets the port to use for the http communication. The bookmarks setting under indexes is the name of the index we will create. Within each index you can have types for each of your entity types, we just have the one type (site) here at the moment.

We have specified that we are using the ORM, the entity class and which fields to map, for now just the name and keywords (I will return to indexing in the url in my next post). That is enough to get any existing Sites stored in the database into the search index. Running the following console command will do this:

php app/console foq:elastica:populate

It is as easy as that! All the sites already stored in the database are now indexed without the need for even writing any code, just a small amount of configuration. Great as that is, it would be even better if we could automatically index any new entities, as well as updating and removing entities as they are updated and removed from the database without having to rerun the console command. This is just as easy to achieve with only one extra item added to the configuration:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            client: default
            types:
                site:
                    mappings:
                        name:
                        keywords:
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        provider:
                        listener:

This enables the bundle’s built in doctrine event listeners which will then do just that, keep the search index up to date with any changes we make to the entities, again without any additional code needed in typical CRUD controllers.

Before looking at searching the index there is one more bit of config which can be added to make integration easy:

foq_elastica:
    clients:
        default: { host: localhost, port: 9200 }
    indexes:
        bookmarks:
            client: default
            types:
                site:
                    mappings:
                        name:
                        keywords:
                    doctrine:
                        driver: orm
                        model: LimeThinking\ExampleBundle\Entity\Site
                        provider:
                        listener:
                        finder:

By adding the finder line we activate the support for returning the search results as Doctrine entities, so the bundle will do the work of fetching the relevant entities from the database after querying the elasticsearch index.

So how do we query the index? The bundle dynamically creates a service you can request from the container with the format foq_elastica.finder.index-name.type-name. These match the values in our config, so the service we need is foq_elastica.finder.bookmarks.site. We can now issue queries using this service:

/**
* @Route("/sites/search/", name="site_search")
* @Method({ "head", "get" })
* @Template
*/
public function searchAction(Request $request)
{
    $finder = $this->get('foq_elastica.finder.bookmarks.site');
    $searchTerm = $request->query->get('search');
    $sites = $finder->find($searchTerm);
    return array('sites' => $sites);
}

Elastica provides an OO query builder for creating more complicated queries but I will leave that for another day. Hopefully I have shown just how straightforward it is to get stated using elasticsearch with a Symfony2 app. As always, it is not limited to such simplicity and you can override these built in services to provide your own providers, finders and listeners if you have more complex requirements.

If you are extending the base controller then its getRequest() method will retrieve the Request object from the container. If you are making your controllers services then you will generally inject in the services, you would have requested from the container, to the constructor or via a setter method. This is not the correct way to work with the Request object as it has a narrower scope than the controller. This basically means that the controller can be used for multiple requests whereas a Request object should only be used for the single request it represents. This means that a fresh request object should be injected each time an action of the controller is called rather than just when the controller is created.

The base controller uses its injected container to get a new Request object each time the action is called, so one way would be to inject the controller itself into the service. There are many reasons not do this which I have covered elsewhere. Fortunately there is a simple way to avoid having to do this, thanks to a cool feature of the framework; Symfony2 will automatically inject the Request object into your actions each time they are called, if you ask for it in the following way:

use Symfony\Component\HttpFoundation\Request;
 
//--
 
public function someAction(Request $request)
{
    // ...
}

The key here is the type hint of Symfony\Component\HttpFoundation\Request, as long as this is in place the Request object will be injected in as a method argument. This avoids any scope issues without having to inject the container. This will work for controllers whether they are services or not and regardless of whether there are any other method arguments. So, for example, you can still combine this with annotated parameter conversion:

use Symfony\Component\HttpFoundation\Request;
use ExampleBunlde\Entities\BlogPost;
 
//--
 
 /**
  * @ParamConverter
  */
public function someAction(BlogPost $blogPost, Request $request)
{
    // ...
}