Tuesday, May 13, 2014

Doctrine2 optimization with APC cache and Symfony2

Some parts of a website are common to every pages and needs to request data from database. To put this data in a cache system is often a first step for optimization. Here is my return on experience about caching data with Doctrine2 in a Symfony2 project.


Before caching data, deal with metadata

Doctrine metadata store informations about entities structure, relations and so on. It's really safe to put in cache memory because it's nearly never changed. Have a look to the config in app/config/config_prod.yml :

# Doctrine Configuration
doctrine:
    dbal:
        ...
    orm:
        metadata_cache_driver: apc

(Still) Before caching data, deal with queries

Doctrine2 uses DQL, its own meta language to generate SQL queries. When you use a QueryBuilder or directly writes your queries in DQL, SQL query is generated each time data are requested. Next config allows Doctrine2 to put generated SQL in cache too. Have a look to the config in app/config/config_prod.yml :

# Doctrine Configuration
doctrine:
    dbal:
        ...
    orm:
        metadata_cache_driver: apc
        query_cache_driver: apc

Finally caching data !

Tuesday, April 22, 2014

Trace IP with Gedmo IpTraceable behavior

As a strong user of Doctrine2 since I'm working with Symfony2, I also use Gedmo DoctrineExtensions. This library provides a great set of useful features we commonly need when developping web project :
  • Timestampable entities (created_at and updated_at columns on tables),
  • Sluggable entities,
  • Trace creators and modificators on contents (Blameable behavior)
  • ...
Since I more often work for sensitive e-commerce project, I needed a feature to trace IPs on some data (mainly orders and payments). So I decided to develop this functionality, based on existing work from Timestampable and Blameable in Gedmo DoctrineExtensions.

This is called IpTraceable and it is well explained in the Github repository documentation.

Symfony bundle implementation is under merge review in Stof DoctrineExtensionsBundle project, and you can use it with your own listener yet. Feel free to comment and add your support to  this PR on github : http://github.com/stof/StofDoctrineExtensionsBundle/pull/233

Tuesday, August 27, 2013

The need to state EntityManager name in a UniqueEntity validation constraint [Symfony2, Doctrine2]

I need to code a backoffice that manages many entities of my sites. Each of my sites has its own bundle with its own database, and a dependency to a common bundle with its own "common" database (for users, logging, billing).

For the same reasons, avoid to access default EntityManager from Container, without naming it... It could lead to an error if you embed your bundle in another application that states another EntityManager as default one...

Doctrine config for site#1

# Doctrine Configuration
doctrine:
    dbal:
        default_connection: site1
        connections:
            site1:
                ...
            common:
                ...
    orm:
        auto_generate_proxy_classes: %kernel.debug%

        default_entity_manager: site1
        entity_managers:
            site1:
                connection: site1
                ...
            common:
                connection: common
                ...

Doctrine config for site#2

# Doctrine Configuration
doctrine:
    dbal:
        default_connection: site2
        connections:
            site2:
                ...
            common:
                ...
    orm:
        auto_generate_proxy_classes: %kernel.debug%

        default_entity_manager: site2
        entity_managers:
            site2:
                connection: site2
                ...
            common:
                connection: common
                ...

Doctrine config for backoffice