Si comme moi, vous avez besoin de travailler avec les multiples connexions de doctrine, vous avez été probablement confronté au bug de la gestion des modèles. Comme les fichiers modèles ne sont pas chargés et que le tableau des loadedModelFiles est vide, doctrine n’instancie pas correctement la connexion, vous vous retrouvez avec la dernière définition d’accès à votre base. Je vous propose ci-dessous une solution à ce problème.

Nous allons donc nous connecter à l’événement « doctrine.configure » dans la configuration de notre projet et définir une fonction qui fera le chargement des modèles. Voici le code à intégrer:

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    ...
    $this->dispatcher->connect('doctrine.configure', array($this, 'listenToConfigureDoctrineEvent'));
  }
  
  public function listenToConfigureDoctrineEvent(sfEvent $event)
  {
    if (!Doctrine_Core::getLoadedModelFiles())
    {
      self::loadModelFiles();
    }
  }
  
  
  protected static function loadModelFiles()
  {
    $dir = sfConfig::get('sf_lib_dir').'/model/doctrine';
    $it = new RecursiveIteratorIterator(
            new RecursiveDirectoryIterator($dir),
                RecursiveIteratorIterator::LEAVES_ONLY);

    foreach ($it as $file)
    {
      $className = str_replace($dir . DIRECTORY_SEPARATOR, null, $file->getPathName());
      $className = substr($className, 0, strpos($className, '.'));
      Doctrine_Core::loadModel(basename($className), $file->getPathName());
    }
  }
}

Voilà. Avec cette nouvelle configuration, vous ne devriez plus avoir de problèmes.

Dans ce nouvelle article, j’ai décidé d’expliquer comment travailler avec les relations M:M de doctrine. La définition de celle-ci dans le fichier schema.yml est assez spéciale. Il faut bien comprendre son fonctionnement pour pouvoir optimiser vos requêtes. Pour cela, j’ai monté un petit exemple concret.

Nous allons commencer par l’écriture de notre modèle au format yml:

---
User:
  tableName:          user
  actAs:
    Timestampable:    ~
  columns:
    id:
      type:           integer(4)
      primary:        true
      autoincrement:  true
      unsigned:       true
    lastname:
      type:           string(80)
      notnull:        true
    firstname:
      type:           string(80)
      notnull:        true
  relations:
    MCategories:
      class:          Category
      local:          user_id
      foreign:        category_id
      refClass:       UserCategory
      foreignAlias:   Users

UserCategory:
  tableName:          user_category
  columns:
    user_id:
      type:           integer(4)
      unsigned:       true
      primary:        true
    category_id:
      type:           integer(4)
      unsigned:       true
      primary:        true
  relations:
    User:
      onDelete:       CASCADE
    Category:
      onDelete:       CASCADE

Category:
  tableName:          category
  actAs:
    Timestampable:    ~
  columns:
    id:
      type:           integer(4)
      primary:        true
      autoincrement:  true
      unsigned:       true
    name:
      type:           string(80)
      notnull:        true
  relations:
    MUsers:
      class:          User
      local:          category_id
      foreign:        user_id
      refClass:       UserCategory
      foreignAlias:   Categories

Comme vous pouvez le voir sur la définition de nos relations, nous n’écrivons pas sur la table de liaison mais sur la table principale (ici User et Category). Nous commençons par leur donner un nom. Ensuite, nous allons insérer toutes les options:

• Class: correspond au modèle de la liaison finale (Category)
• local et foreign: correspondent aux champs définis dans votre table de liaison.
• refClass: Nom du modèle de liaison (UserCategory)
• foreignAlias: Le nom de l’alias qui sera donné à notre table finale (Category)

Un petit fichier de fixtures pour avoir des données de test:

---
User:
  user_1:
    firstname:    Adrien
    lastname:     Loutier
    MCategories:   [cat_1, cat_2, cat_3]
  user_2:
    firstname:    Simon
    lastname:     Jacquemoud
    MCategories:   [cat_2, cat_4]
  user_3:
    firstname:    Raphaëlle
    lastname:     Tabouret
    MCategories:   [cat_1, cat_2, cat_3, cat_4]
  user_4:
    firstname:    Justine
    lastname:     Simonin
    MCategories:   [cat_2, cat_3, cat_4, cat_5]

Category:
  cat_1:
    name:         Niveau 1
  cat_2:
    name:         Niveau 2
  cat_3:
    name:         Niveau 3
  cat_4:
    name:         Niveau 4
  cat_5:
    name:         Niveau 5

J’ai ensuite généré un module « user » pour pouvoir y insérer mon code. Je passe sur les explications de cette génération.

Nous avons maintenant deux solutions. Soit nous laissons travailler doctrine sans optimisation, soit nous définissons notre requête pour avoir un minimum d’appels sur la base de données.

Dans le premier exemple, nous allons laisser faire doctrine. Nous allons simplement appeler nos users dans le fichier actions.class.php de notre module:

class userActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->users = Doctrine_Core::getTable('User')
    ->createQuery()
    ->execute();
  }
}

Affichage de nos données dans notre template. Ici indexSuccess.php

<h1>Liste des utilisateur</h1>
<?php foreach ($users as $user): ?>
<p>
  <?php echo $user->firstname; ?> <?php echo $user->lastname; ?>
  <ul>
  <?php foreach($user->getCategories() as $categorie): ?>
  <li class="list"><?php echo $categorie->name; ?></li>
  <?php endforeach; ?>
  </ul>
</p>
<?php endforeach; ?>

Dans le code ci-dessus, j’utilise le get{Categories} (foreignAlias de la relation sur la table User) pour récupérer mes catégories. Vous n’avez pas besoin d’appeler les enregistrements de la table de liaison.

Nous avons le résultat suivant en html:

Nous allons maintenant visualiser le nombre de requêtes effectuées par doctrine dans notre barre de debug (Cliquez sur l’image pour visualiser):

Nous constatons que doctrine exécute 5 requêtes (une par personne pour récupérer les catégories).

Nous allons maintenant optimiser notre récupération de données en écrivant une requête DQL dans le modèle User. Le fichier se trouve dans lib/model/doctrine/UserTable.class.php:

class UserTable extends Doctrine_Table
{
  public function getActiveCategories()
  {
    return $this->createQuery('u')
    ->leftJoin('u.Categories g')
    ->execute();
  }
}

Dans la requête ci-dessus, nous utilisons également le nom de la foreignAlias pour écrire notre jointure.

Nous allons changer notre précédente requête dans l’action index par celle-ci:

class userActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->users = Doctrine_Core::getTable('User')->getActiveCategories();
  }
}

Nous retournons dans notre barre de debug pour visualiser les requêtes (Cliquez sur l’image pour visualiser):

Comme vous pouvez le constater ci-dessus, avec l’optimisation du DQL, Doctrine exécute une seule requête.

Voilà. J’espère que ce petit exemple pourra vous servir pour vos prochains développements. N’hésitez pas à me laisser vos commentaires.

Symfony ne proposant pas une fonctionnalité me permettant de définir un message en cas de non disponibilité de la base de données, j’ai réalisé un filtre pour contrôler cela. Pour le rendre flexible, j’ai ajouté deux options permettant la définition du module et de l’action appelé lors de l’erreur.

J’ai commencé par créer dans mon module default, une action checkAvailibility me permettant de réaliser un template pour l’affichage du message (je passe sur cette étape car je pense que vous savez le faire). Ensuite, il suffit de les définir dans le fichier app.yml:

all:
  checkdb:
    module: default
    action: checkAvailibility

J’ai ensuite créé mon fichier filtre appelé « checkAvailibilityDbFilter.class.php » dans le dossier /lib de mon projet:

class checkAvailibilityDbFilter extends sfFilter
{
  public function execute($filterChain)
  {
    if ($this->isFirstCall())
    {
      $context = $this->getContext();

      $module = sfConfig::get('app_checkdb_module', 'default');
      $action = sfConfig::get('app_checkdb_action', 'error404');

      if (($module != $context->getModuleName()) || ($action != $context->getActionName()))
      {
        $configuration = sfProjectConfiguration::getActive();
        $db = new sfDatabaseManager($configuration);
        
        foreach ($db->getNames() as $connection)
        {
          try
          {
            @$db->getDatabase($connection)->getConnection();
          } 
          catch(Exception $e)
          {
             $context->getController()->forward($module, $action);
             exit;
          }
        }
      }
    }
    
    $filterChain->execute();
  }
}

Il reste encore à activer ce filtre pour que cela fonctionne. J’ai ajouté les lignes suivantes dans le fichier filters.yml du dossier config de l’application:

rendering: ~
security:  ~

# insert your own filters here
db:
  class:  checkAvailibilityDbFilter

cache:     ~
common:    ~
execution: ~

J’espère que cette petite astuce vous sera utile.

Note préalable: Nous utilisons dans cette article le système de cache php APC. Vous devez installer celui-ci sur votre configuration pour que l’exemple ci-dessous fonctionne.

Doctrine a en standard la possibilité de mettre en cache les résultats d’une requête. Il propose entre autre Memcached, APC, Sqlite. Nous allons l’utiliser dans le cadre d’un exemple symfony.

Pour commencer, nous allons initialiser une variable contenant la durée de vie du cache dans le fichier app.yml de notre application:

all:
  cache:
    lifetime: 3600

Nous allons maintenant initialiser le cache APC de doctrine. Le code ci-dessous est à mettre dans la classe de configuration de votre application:

class frontendConfiguration extends sfApplicationConfiguration
{ 
  public function configure()
  {
  }

  public function configureDoctrine(Doctrine_Manager $manager)
  {
    /* Initialisation du cache Doctrine APC */
    $cacheDriver = new Doctrine_Cache_Apc();
    $manager->setAttribute(Doctrine::ATTR_QUERY_CACHE, $cacheDriver);
    $manager->setAttribute(Doctrine::ATTR_QUERY_CACHE_LIFESPAN, sfConfig::get('app_cache_lifetime'));
    $manager->setAttribute(Doctrine::ATTR_RESULT_CACHE, $cacheDriver);
    $manager->setAttribute(Doctrine::ATTR_RESULT_CACHE_LIFESPAN, sfConfig::get('app_cache_lifetime'));
  }
}

Pour cette exemple, j’utilise le modèle suivant:

---
dUser:
  tableName:  d_user
  columns:
    id:
      type: integer(3)
      primary:  true
      autoincrement:  true
    fullname:
      type: string(160)
      notnull:  true
    street:
      type: string(160)
    zip:
      type: string(10)
    city:
      type: string(80)
    country:
      type: string(60)

Dans la classe du modèle ci-dessus, nous allons utiliser le cache. La directive useResultCache est ajouté à la requête.

class dUserTable extends Doctrine_Table
{
  public function findFullnameOrderByAsc()
  {
      return $this->createQuery('u')
                         ->select('u.fullname, u.city')
                         ->orderBy('fullname')
                         ->useQueryCache()
                         ->useResultCache()
                         ->execute();
  }
}

Il vous suffit ensuite d’exécuter votre requête dans votre action avec le code suivant pour récupérer le résultat.

$this->users = Doctrine::getTable('dUser')->findFullnameOrderByAsc();

Si vous utilisez la debug toolbar, vous constaterez qu’à la première requête, vous aurez 1 appel à la base de donnée mais que si vous rechargez votre page html, aucune nouvelle requête n’est lancée. Le cache fonctionne.

J’espère que ce point de départ vous aidera dans vos découvertes. N’hésitez pas à poster vos découvertes dans les commentaires.

Merci à [MA]Pascal pour la piste de configuration.

Références:
– Documentation Doctrine sur le cache
– La documentation du cache PHP alternatif APC
– L’extension php apc

Article:
– Performance Tuning in PHP