Requête natives avec Symfony 2 et doctrine.

Quand on est développeur, à chaque fois qu’on résout un problème, c’est pour en trouver un autre derrière.

Je sortais à peine de ma dernière galère que voilà que j’ai replongé dans une nouvelle : les requête avec Doctrine.

Oui, parce que Doctrine, c’est beau, ça brille, ça donne envie. Mais… Non. Le nouveau constructeur de requête ne tiens pas ses promesses et on atteint très très vite ses limites. Contrairement à son ancienne version qui montrait une grande robustesse et une grande simplicité, vous aurez probablement très vite besoin d’utiliser avec la version 2 ce qu’on appelle des « requêtes natives » (native query dans la langue de Shakespeare).

mais bon, comme vous vous en foutez un peu de ma vie, ne prolongeons pas plus cette introduction.

Le constructeur de requêtes

Doctrine nous offre comme outil principal le constructeur de requête (query builder). Il est très simple et fonctionne très bien pour des requête basique :

$query = $this->createQueryBuilder('u')
->addSelect("SUM(CASE WHEN kComp.slug is not null THEN 1 ELSE 0 END)")
->leftJoin('u.keywords', 'kComp', \Doctrine\ORM\Query\Expr\Join::WITH, '1 = 1')
->where('u.id <> :userId')
->groupBy('u.id')
->orderBy('u.lastLogin', 'ASC')
->setParameter('userId', $_search->getUser()->getId())
;

Donc comme on peut le voir, ça fourni quand même toutes les fonctionnalités de bases :

  • ajout de champs personnalisés,
  • jointures strictes via innerJoin ou jointures flottantes via leftJoin, avec possibilités d’ajouter des conditions supplémentaire via le mot clef « WITH »
  • les conditions where
  • les classiques « order by »
  • et enfin l’utilisation de paramètres personnalisés avec la méthode « setParameter » qui remplacera automatiquement les variables par leurs valeurs.

Seulement, de nombreuse fonction ne sont pas reconnues, comme par exemple le « IF » mysql. De plus, Doctrine ne permet pas (plus) d’écraser les conditions ON ce qui s’avère beaucoup plus bloquant.

C’était pourtant ce qui rendaient Doctrine 1 vraiment plaisant à utiliser, on pouvait simplement écraser les jointures ON avec « ->innerJoin(‘u.Relation ON u.condition = « new_condition »‘« . Ce n’est malheureusement plus possible.

Alors comment faire quand on veut exécuter une requête un poil plus intéressante ? Et bien c’est le chapitre suivant…

Les requêtes natives

Doctrine nous fournie pour se faire la possibilité de lancer directement des requêtes natives. Malheureusement, elles sont beaucoup moins « user friendly », surtout si vous utilisez Symfony 2.3 ou inférieur.

La première chose à faire dans ce cas, c’est de mettre à jour l’ORM vers la version 2.4. En effet, Symfony utilise une version inférieur de l’ORM par défaut, et elle est bourrée de bugs au niveau des requêtes natives, ce qui les rend inutilisables.

Ouvrez donc le fichier composer.json à la racine de votre projet et modifiez-le pour redéfinir les dépendances tel que :

"require": {
...,
"doctrine/orm": "~2.4",
...,

Ensuite, ouvrez un terminal et lancez la commande ./composer.phar update pour effectuer la mise à jour de la nouvelle version de l’ORM Doctrine.

Maintenant, nous pouvons enfin créer notre requête native :

// init vars
$where = '';
$parameters = array();

// tout d'abords, nous créons le builder pour mapper les résultats en entités doctrine compréhensible :
$rsm = new ResultSetMappingBuilder($this->_em);
$rsm->addRootEntityFromClassMetadata('My\UserBundle\Entity\User', 'u'); // on définie l'entité de base qui apparaîtra dans le FROM
$rsm->addScalarResult('compatibility', 'compatibility'); // on déclare notre champ personnalisé
$rsm->addJoinedEntityFromClassMetadata('My\UserBundle\Entity\Keyword', 'kComp', 'u', 'keywords', array(
'id' => 'kCompid',
'title' => 'kComptitle',
)); // et enfin, on ajoute les relations que l'on désire récupérer. Notez qu'il faut obligatoirement renommer manuellement les champs qui ont le même nom que ceux que l'on pourrait trouver dans l'entité principale, ici "id" et "title".

// maintenant, nous allons définir des conditions manuellement
if ($_search->getTitle() !== null) {
$where .= ' AND u.title = :title';
$parameters['title'] = $_search->getTitle();
}

// On rédige la requête en sql. On insère l'objet de mapping des résultat en tant que select et les conditions WHERE. Remarquez qu'on peut maintenant tout à fait écraser les jointures et en créer plusieurs.
$sql = 'SELECT ' . $rsm . ', SUM(CASE WHEN kComp.slug = kSearch.slug THEN 1 ELSE 0 END) as compatibility
FROM `fos_user` u
LEFT JOIN keyword kSearch ON kSearch.user_id = :userId
LEFT JOIN keyword kComp ON kComp.user_id = u.id AND kComp.slug = kSearch.slug
WHERE u.id <> :userId ' . $where . '
GROUP BY u.id
ORDER BY u.last_activity ASC'
;

// Il ne reste plus qu'à créer l'objet de requête native et à lui passer les paramètres qu'on a défini plus haut.
$query = $this->_em->createNativeQuery($sql, $rsm);
$query->setParameters($parameters);
$query->setParameter('userId', $_search->getUser()->getId());

Voilà, maintenant vous pouvez récupérer le résultat de votre requête correctement hydraté en objet Doctrine !


Remerciement à FrozenFire du channel irc #doctrine pour son aide 😉

 

Symfony2, c’est plus du tout magique.

Symfony 1.X, c’était magique !

À la base, j’aimais pas trop le PHP. Outre le fait que c’est un langage que je n’ai jamais apprécié,  que se soit à cause de sa lourdeur générale que de sa syntaxe permissive (yes, tu fais n’importes quoi, tu as n’importes quoi !), créer un site web était pour moi une vraie plaie. Il fallait tout le temps vérifier les données, rajouter des filtres pour empêcher les injections de codes, toujours réécrire les mêmes bout de code à chaque fois…

Et puis j’ai découvert… Symfony !

Et là, le plaisir : on crée son schéma de BDD, symfony doctrine:build-all… Et c’est fini.

Symfony créait tout seul les modules CRUD, l’admin, les forms, les filters, la connexion à la base est sécurisée, symfony et doctrine s’occupaient de tout.

Certes, tout n’était pas parfait. Il restait notamment deux lacunes très contraignantes pour moi : l’impossibilité de surcharger un plugin avec un autre plugin, et le fait que Symfony1.X ne gérait pas l’imbrication de formulaires multiples.

  Symfony2 : la chute

Avec une base de travail aussi excellente que Symfony1.X, on aurait pu s’attendre à un framework inégalable. Symfony2 aurait pu être le paradis des développeurs web !

Hélas, Sensio a fait un autre choix : repartir de 0.

Adieu le fameux « schema.yml ». Adieu la génération des modèles, des formulaires, des filtres. Adieu l’admin-générator.

Bref, avec l’intention, certes louable, de vouloir apporter des pratiques de développement encore meilleures que chez son grand frère, on a vu disparaitre tout ce qui faisait la puissance de ce dernier.

Alors oui, c’est plus performant. Oui, le code est plus propre… mais le plaisir n’est plus là.

La première chose qui frappe, c’est la documentation. Alors que Symfony1 présentait une documentation exemplaire, traduite dans les langues majeures, toujours à jour, avec un tutoriel retraçant la création d’une application en conditions réelles de A à Z en 24 jours, Symfony2 ne propose plus qu’une documentation succincte, uniquement en anglais, et pas toujours à jours puisque le framework évolue en permanence.

La seconde chose qui frappe est donc la disparition du fameux fichier schema.yml. La nouvelle politique est qu’il faut créer soit-même les entités (qui correspondent à des tables de la base de donnée, par exemple l’entité « user » correspond à la table « user »). Chaque entité est un fichier php et Symfony les gère via un système d’annotation:

/**
 * @ORM\Column(type="string", length=255)
 *
 * @Assert\NotBlank(message="Please enter your firstname.", groups={"Registration", "Profile"})
 * @Assert\MinLength(limit="3", message="The name is too short.", groups={"Registration", "Profile"})
 * @Assert\MaxLength(limit="255", message="The name is too long.", groups={"Registration", "Profile"})
 */
protected $firstname;

Je suis peut-être vieux-jeu, mais pour moi, les commentaires sont fait pour « commenter », ils sont destinés à la documentation. D’ailleurs vous remarquerez très vite que votre IDE est inutile puisqu’il ne reconnait pas les annotations…

Bref, tout est sur ce modèle du « do it yourself ». Tu veux le formulaire de ton entité ? fais le toi même. Tu veux le contrôleur, idem.

Les commandes proposées par Symfony2 se contentent du minimum syndicale.

Toutefois, tout n’est pas noir, ça reste un bon framework sur le papier, notamment grâce aux nombreux bundles disponibles, comme le fameux FOSUserBundle qui propose un système très complet et complètement paramétrable pour gérer les utilisateurs. De plus, il est maintenant très facile de surcharger un bundle avec un autre bundle. Enfin il semble que les formulaires imbriqués soit théoriquement bien gérés (quoi que chez moi, sur la version 2.1 en pre-release, c’est loin d’être le cas :p).

Conclusion

Symfony2 a deux problèmes majeurs à mes yeux : premièrement il perd son côté « magique ». Et du coup tout son intérêt. Certes, on gagne en performance, on gagne en propreté, mais on continue d’utiliser PHP. Hors, PHP reste (et restera probablement encore longtemps) un langage médiocre. En perdant sa magie, Symfony a du coup perdu tout son intérêt en face des frameworks réellement performants comme Play! (Java/Scala), Django (Python) ou Ruby On Rail (dois-je préciser ?) qui, avec une logique similaire, resteront toujours incomparablement plus performants.

Deuxièmement, Symfony2 a été relâché beaucoup trop tôt. Encore aujourd’hui, les formulaires, qui sont sûrement le composant majeur de Symfony sont en constante évolution. Certes, j’utilise la pre-release, mais cela me permet de constater l’évolution constante de ce framework qui est loin d’être abouti.