Doppar’s Temporal ORM, présenté dans cet article de Mahedi Hasan, est une solution PHP innovante permettant de conserver et interroger l’historique complet des modifications d’un enregistrement en base de données. L’idée centrale est d’intégrer nativement cette fonctionnalité dans le framework, évitant ainsi les approches traditionnelles comme les logs manuels ou les packages externes, souvent coûteuses en maintenance. L’ORM capture automatiquement chaque changement (création, mise à jour, suppression) et le stocke dans une table dédiée, offrant ensuite une API intuitive pour naviguer dans le temps, comparer des états ou restaurer des versions antérieures.
L’article explique que cette fonctionnalité s’inspire des standards SQL:2011 pour les tables temporelles et d’outils comme Hibernate Envers (Java) ou Paper Trail (Ruby), mais est repensée pour PHP 8.3 avec des attributs modernes et une configuration minimale. L’objectif est de traiter l’audit comme une capacité native du framework plutôt qu’un module externe, réduisant ainsi la complexité et les risques d’erreurs.
Enfin, la mise en œuvre est simplifiée : il suffit d’ajouter l’attribut #[Temporal] à un modèle pour activer le suivi automatique. L’ORM gère les snapshots en JSON, les métadonnées (date, utilisateur, etc.) et propose des méthodes fluides pour interroger le passé, comme Contract::at('2024-01-01')->find(42).
L’auteur explique comment optimiser Doctrine ORM pour éviter non seulement le problème classique du N+1, où l’accès aux relations dans une boucle génère des dizaines voire centaines de requêtes, mais aussi le piège du produit cartésien qui survient lorsqu’on tente de tout charger en une seule requête avec de nombreux LEFT JOIN : bien que n’affichant qu’une requête dans le profiler, ce type de jointures multiplie les lignes SQL retournées (chaque combinaison de collections), ralentit la page et surcharge Doctrine lors de l’hydratation des objets. La solution proposée repose sur une hydratation en plusieurs étapes en chargeant d’abord les entités principales avec une relation, puis en « primeant » séparément les autres relations via des requêtes successives utilisant l’Identity Map de Doctrine, ce qui aboutit à quelques requêtes légères et prévisibles sans explosion des résultats.
L’article défend l’importance des bases de données relationnelles comme exemple de « boring technology » sous-estimée, soulignant que malgré leur large utilisation pour stocker des données, beaucoup de développeurs ne maîtrisent plus le SQL ni les fonctionnalités avancées des SGBD, ce qui se révèle problématique quand les charges augmentent et que les performances chutent ; il ajoute que les ORM sont utiles mais doivent être bien compris pour optimiser les requêtes et exploiter pleinement des concepts comme vues, index ou requêtes récursives afin de bâtir des applications robustes sans multiplier inutilement les technologies.
L'auteur partage son expérience d'optimisation de traitement de données pour son blog, passant de plusieurs heures à quelques minutes. Il explique son architecture basée sur l'event sourcing pour analyser les visites, stockées dans une base de données et traitées par différents projecteurs. Face à un problème de performance lors de la reprocessus de 11 millions de lignes, il décrit son approche pour améliorer les performances, en commençant par établir une ligne de base de 30 événements par seconde.
Cet article explique pourquoi Doctrine ORM sauvegarde les modifications des entités même sans appeler la méthode persist(). Le mécanisme clé est le "dirty checking" : Doctrine suit les entités gérées (chargées depuis la base de données), compare leurs valeurs actuelles avec une copie initiale, et génère des requêtes SQL uniquement pour les champs modifiés lors de l'appel à flush(). La méthode persist() n'est nécessaire que pour les nouvelles entités.
Tout est dans le titre
3 conférences résumées :
- L’aventure d’une requête HTTP — ou le chemin de la vie des devs -> il y a tant de concepts derrière que le conférencier insiste sur la modestie à avoir et sur le fait de se reposer sur ses coéquipiers
- Et si on repensait les ORMs ? -> présentation de l'ORM Format, un concurrent de Doctrine / Eloquent basé sur d'autres concepts (très bien fait pour le DDD)
- Webhooks at scale -> Le speaker présente le concept de Circuit Breaker
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur donne son opinion sur l'intérêt ou non de découpler totalement les entités de l'ORM / Framework / ... Pour résumer, il faut que le modèle puisse être testé "en isolation" (sans base de données) mais y mettre des annotations (par exemple, Doctrine) n'est pas contre indiqué -> cela ne rend pas le modèle moins testable.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... mais les principes exposés ici s'appliquent à d'autres ORM comme Doctrine (a priori ?)
présentation de l'ORM Eloquent (utilisable avec le framework PHP Laravel)