Jusqu’à l’AFUP Day 2023, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Doctrine, objet typé, et colonne JSON Les bases de données savent gérer des colonnes JSON depuis des années déjà, et ces colonnes permettent d'accélérer le développement en simplifiant le code, les migrations et la maintenance. Cependant, manipuler un array PHP n'est pas pratique : les analyseurs statiques de code sont perdus (à moins de spécifier énormément de chose via de la PHPDoc), PHP ne peut pas contrôler le type au runtime, mais surtout la lisibilité du code est réduite. En effet, à moins de lire tout le code, il est difficile de savoir quelles sont les clés obligatoires, lesquelles sont optionnelles, et enfin comment est typée la donnée. À travers cette présentation, nous allons voir comment étendre Doctrine pour avoir le meilleur des deux mondes : des colonnes en JSON, et des objets PHP fortement typés.

Université Catholique de Lille 12/05/2023 09:20-10:00

Le JSON a des avantages comme des inconvénients. Quelles sont les situations pour lesquelles c’est tentant de l’utiliser, alors qu’il faudrait s’abstenir ?

J’utilise énormément les colonnes JSON quand il n’y a pas de contrainte d’intégrité sur la donnée. Par exemple, quand il n’y a pas de clés étrangères. Concrètement, quand il y a de la configuration (d’un produit), des préférences (d’un utilisateur), une colonne JSON est très adaptée. Elle nous apporte beaucoup de souplesse et évite les modifications de schémas.

Cependant, une colonne JSON n’est pas adaptée à toutes les problématiques. Dans beaucoup de situations, le respect des formes normales (jusqu’à la 3eme) est préférable. Il permet de réduire la duplication d’information au sein de la base de données.

De plus, avec l’utilisation d’ORM comme Doctrine, le JSON est lu et écrit en bloc (toute la valeur en un coup), ce qui peut poser des problèmes de concurrence, et d’écriture de requête SQL. Cependant, j’utilise très souvent des natives queries au lieu de passer par le QueryBuilder pour pallier ce dernier problème.

Est-ce qu’une view au sens SGBD pour mettre à plat les données d’une colonne JSON pourrait réduire le coût de lecture ?

Je n’ai jamais fait l’expérience, alors je ne saurais pas répondre à cette question. Cependant, je ne vois pas l’intérêt de mettre à plat une colonne JSON. De plus, si le JSON a plusieurs dimensions, ça ne sera pas possible. Et finalement, je ne pense pas qu’ajouter un layer puisse accélérer les choses. À moins que la vue ne soit concrète.

J’aimerais ajouter que je n’ai jamais eu de problème de performance sur la lecture d’une colonne JSON.

Tu es membre de la Core Team Symfony, est-ce que tu sais si de nouveaux composants seront prochainement annoncés ?

Je suis très heureux de voir 3 (ou 4) nouveaux composants arriver dans Symfony ! Nous utilisons déjà quelque chose de similaire à Webhook et à RemoteEvent. J’ai hâte de supprimer notre code pour le remplacer par celui de Symfony. Comme je le dis souvent : moins de code == moins de bug !

Pour le Scheduler, l’idée d’utiliser un transport (messenger) à base de générateur me plaît beaucoup. Je n’ai pas encore pris le temps de jouer avec, mais j’ai hâte !

Enfin, je ne sais pas si ImportMap(s) va être mergé pour la 6.3, mais j’ai vraiment envie de le tester sur un « pet project » avec Symfony UX que j’adore ! (Spoiler : il est prévu d’open sourcer ce projet dans les semaines qui arrivent)

Et pour conclure sur Symfony 6.4 : comme d’habitude, il n’y a pas vraiment d’objectif. C’est la communauté qui décide de la direction du framework à travers des issues et pull request sur GitHub. Cependant, on peut sentir une grosse tendance à l’ajout d’attributs PHP, d’améliorations de la DX et de la performance.

Une conférence présentée par

Gregoire PINEAU

Arrivé en 2017 dans l’équipe de JoliCode, Grégoire a toujours aimé bidouiller, comprendre et apprendre. À l’issue d’études éclectiques, il est revenu au Web en 2010, domaine dans lequel il exerce depuis avec passion. Après avoir appris à se servir du framework Symfony, il a passé sa certification, puis a commencé à contribuer timidement… Ce qui l’a mené, quelques années après, à devenir un des core contributeurs du projet ! Durant toutes ces années, il a toujours préféré le backend au frontend – même s’il apprécie React, Sass et ces autres joyeusetés, il s’amuse davantage avec Ansible, Terraform ou Consul. Vous pourrez le croiser lors de meetups, ou dans des matches de volley 🙂

Autres intervenants