Retour d'expérience: Pomm est mûr, abandonnons les ORM

L'abandon d'un ORM au profit de Pomm, retour d'expérience.

Introduction

Chez Sismic, nous utilisons Pomm sur tous nos projets. Je vais vous retracer les étapes qui ont constituées notre passage de Propel (ORM) vers Pomm.

Comme beaucoup de développeurs PHP, j'ai débuté avec MySQL et PDO. Les projets se succèdent, un jour on est lassé d'écrire du SQL et très vite on se retrouve à utiliser un ORM.

A ce moment là une nouvelle vie commence, on se sent léger et puissant avec l'impression de pouvoir se concentrer sur son code métier.

L'ORM possède de nombreux avantages, l'un des principaux étant de pouvoir s'interfacer avec plusieurs SGBD.

Seulement, cet avantage est également sa plus grande faiblesse. En effet pour garantir une parfaite compatibilité, il est obligé d'utiliser des fonctionnalités communes, et donc de faire l'impasse sur certaines spécificités propres à tel ou tel moteur de base de données qui n'éxistent pas partout.

Si cela n'est pas dommageable pour Mysql, c'est bien différent avec PostgreSQL.

La découverte de Pomm, QUÉSACO ?

L'essayer, c'est l'adopter. C'est un peu le résumé de mon passage de Mysql vers PostgreSQL. Au fil du temps, l'envie d'en découvrir plus sur ce SGBD se fait ressentir.

Une envie très vite rendue impossible, à cause des limitations de l'ORM #frustration.

C'est lors d'une discussion dans les couloirs du célèbre évènement de l'AFUP (le Forum PHP) que j'ai découvert le projet Pomm

Lorsque je m'y suis interressé, celui-ci était encore en v1, la v2 étant alors en cours de développement. J'ai tout de même choisi cette dernière, pariant sur l'avenir mais également conseillé par Grégoire Hubert - @chanmix51, owner de Pomm.

Premiers pas, premiers Doutes

La promesse de Pomm était forte : Utiliser pleinement la puissance de Postgres. Youuuhouu !

Pomm est divisé en plusieurs briques :
- Foundation - ModelManager - Cli

Sans comprendre réellement le but de cette division, je commençais avec un projet Silex et insérais la full stack Pomm.

L'un des chevaux de bataille du projet étant de se vouloir simple et facilement appréhendable, la prise en main a été très rapide.

Je paramètre le DSN, exécute une commande avec le CLI et me voilà dans le Vortex Pomm.

Rapidement, je réalise mes premières requêtes avec le ModelManager pour effectuer les fonctions de CRUD classiques : findByPk, findWhere...

Puis l'envie me prend soudain de récupérer une liaison grâce à une Foreign Key. Avec Propel j'aurais fait un ->leftJoinFK mais là?

Quoi? je dois écrire une requête SQL?

Pendant 2 secondes, un petit moment de solitude me gagne... Puis, rapidement, la mémoire me revient: Left Join, Inner Join, tant de mots clés non utilisés depuis bien longtemps!

Après plusieurs années, me voilà à réecrire mes requêtes SQL !

C'est génial, mais là je passe plus de temps qu'avant à obtenir un résultat identique ... Dans ce cas, quel avantage Pomm m'apporte t'il ?

Changer sa façon de penser

Bien décidé à utiliser pleinement cette puissance promise, je lisais en parallèle des articles sur PostgreSQL.

Le premier d'entre eux me parlait des Schémas. J'ai découvert que "public" n'était pas là que pour ajouter une étape dans le parcours d'accès à ma base et faire plus Geek que Mysql ^^ ?

Et bien non! celà a une vraie utilité, dont voici le détail schémas PostgreSQL.

Ensuite j'entend parler de JSON, Hstore, Tsrange, Array... PostgreSQL contiendrait donc d'autres types de données que integer, varchar... ?

Cela fut sans doute mon plus grand bouleversement. Stop ! j'ai déjà stocké de l'Array avec Propel !

En fait les ORM se devant de garder une compatibilité avec tous les SGBD, mon array était en fait stocké sous la forme d'une chaîne parsée o_O. PostgreSQL, lui, peut stocker réellement un array et grâce a Pomm plus besoin de parsing. J'envoie et reçois un Array à Postgres.

Je commencais à comprendre qu'il fallait arréter de penser ORM ! et celà fût sans doute l'étape la plus difficile.

Je compare celà au passage Procédural => Objet. Au départ, on a l'impression de perdre du temps puis très vite on découvre la force des choses, la maintenabilité...

Lors de mes tests pour intégrer Pomm à mes projets existants avec Propel, une de mes premières erreurs fut de négliger la structure de la base de données. Conserver une struture de base de données dictée par l'utilisation d'un ORM (Propel, Doctrine ou autre) couplée avec Pomm ne présente finalement aucun intéret et je ne saurais que trop vous conseiller uné ré-organisation au moins partielle de votre base.

La montée en puissance, la re-découverte de Postgres

Mon cerveau commencant à se faire à l'idée, je décidais d'en apprendre plus sur Pomm, aider et supporter par la petite mais très présente team du projet sur le channel IRC : irc.freenode.net #pomm.

Dans mes projets, je dois souvent mettre en place des tableaux de statistiqures, des graphiques etc... Jusqu'à la découverte de Pomm, cela était une réelle corvée.

Je devais écrire des scripts de plusieurs lignes avec l'ORM pour tenter de récupérer des datas sur des dizaines de tables différentes et faire des SUM, des distincts...

Ce genre de script est très peu debuggable et maintenable, et que dire de l'exploitation des résultats obtenus ? Des boucles imbriquées et des conditions en tout genre pour tenter d'obtenir quelque chose d'exploitable.

C'est là qu'intervient Foundation ! Pourquoi vouloir modéliser en objet ce genre de données ?

Ce que l'on souhaite, c'est afficher des tableaux de stats. Alors pourquoi ne pas faire une simple projection du résultat que l'on veut obtenir? C'est exactement ce que permet Foundation en bénéficiant des avantages de Pomm.

Dans ces tableaux de statistiques, on doit souvent calculer les totaux. Quelle solution ? une autre requête ? calcul des totaux lors de la boucle d'affichage? Pourquoi faire compliqué lorsque c'est déjà disponible en natif avec les WITH Queries ?

Une grande étape a été de redonner du sens à mon SGBD en lui intégrant la gestion de certaines contraintes métier, notamment grâce à des triggers.

Le but étant de permettre à la base de données de pouvoir garder son "intégrité métier" de manière autonome, peu importe le client qui interragit avec elle.

Conclusion

Presque 2 ans se sont écoulés et Pomm fait maintenant partie de notre quotidien et est déployé en production sur des projets Silex, Symfony2 & Symfony3 ou from scratch.

Chez Sismic, Pomm nous a permis de gagner en efficacité. Notre code est beaucoup plus maintenable et évolutif.

Cela à également permis de réduire considérablement le temps de formation lors de nouveau recrutement et de réduire la prise en main des projets.

Pomm convient à tout type de projet grâce à son découpage: Des applications complexes grâce au Model Manager, des applications ayant besoin d'une interface simple a PostgreSQL grâce à Foundation, mais également des workers grâce au CLI.

Vous l'aurez compris, la plus grande difficulté de Pomm est la remise en question obligatoire de nos habitudes et la volonté de vouloir arréter de snober le SQL.

La plus grande force de Pomm est de se faire oublier et de n'avoir aucune contrainte pour communiquer et exploiter la puissance de PostgreSQL.

Aujourd'hui, l'équipe s'est agrandie, la formation a été simple et l'équipe découvre chaque jour des fonctionnalités un peu plus avancées de Postgres.

Tags: pomm, PostgreSQL, php

Notification des erreurs applicatives vers Slack via Monolog

Notification des erreurs applicatives vers Slack via Monolog

Le contexte

Chez Sismic, nous sommes tous en télétravail. Nous avons donc besoin d'un outil de communication nous permettant d'échanger entre nous sur différents sujets, que ce soit sur les projets en cours, l'organisation, les plannings ou tout autre sujet de discussion. Il faut également que nous ayions accès à l'historique des communications des membres de l'équipe, même lorque nous sommes hors ligne (ce qui bien entendu ne devrait jamais arriver :D).

C'est pour cette raison que nous avons opté pour Slack.

Nous développons des applications [Symfony 2] (http://symfony.com) pour nos différents clients, avec Monolog pour la gestion des logs applicatifs. Lorsqu'une erreur arrive sur une de nos applications, elle est enregistrée dans le fichier log du projet.

Malheureusement, les fichiers logs sont généralement consultés par nos équipes seulement après que l'erreur nous ait été signalée, que ce soit par les clients ou bien par un internaute. Une première solution a été de mettre en place une notification par mail, seulement cette solution a vite trouvé ses limites lors du départ en vacances du premier développeur :).

Envoyer les notifications d'erreurs de nos applications vers un channel Slack via Monolog

Pour gagner en réactivité, il nous faut donc pouvoir récupérer en temps réel les notifications d'erreur sur un canal de communication accessible à n'importe quel moment par l'équipe de développement. Nous avons justement ce canal de communication à notre disposition: notre outil de communication Slack. Chaque membre de l'équipe de développement s'y connecte en début de journée et est connecté durant toute sa journée de travail (et même plus si affinité! ). Il aurait donc été intéressant de pouvoir utiliser également cet outil pour recevoir les erreurs critiques de nos applications.

Ca tombe bien, Monolog dispose d'un handler Slack qui permet d'envoyer les erreurs ayant un certain niveau de criticité minimum vers un channel Slack pré-défini: https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/SlackHandler.php

Voici les étapes pour le paramétrage de cette fonctionnalité :

  • Créer un nouveau channel Slack Il faut se rendre sur la page de création de channel et créer un nouveau channel privé.

  • Générer un token d'identification pour autoriser notre application Symfony (ou toute autre application utilisant Monolog pour enregistrer ses logs) à envoyer des données à Slack. Authentication

  • Paramétrer la communication entre Slack et Monolog dans config_prod.yml (config_dev.yml pour tester en développement).

parameters.yml

parameters:
    slack_token: slack-token
    slack_channel: "#nom-du-channel-slack"
    slack_bot: nom-du-bot-slack
    slack_emoji: :logo-a-utiliser:
    slack_level: error # Niveau d'erreur minimum qui enverra une notification au channel Slack

config_xxx.yml

monolog:
    handlers:
        slack:
            type:       slack
            token:       %slack_token%
            channel:     %slack_channel%
            bot_name:    %slack_bot%
            icon_emoji:  %slack_emoji%
            level:       %slack_level%
            include_extra: true
  • Et l'appel de l'erreur dans l'application:

    $this->get('logger')->error('Error Message', [ 'parameter1' => 'value1', 'parameter2' => 'value2', 'parameter3' => 'value3', 'parameter4' => 'value4', ]);

Conclusion

Voilà, j'espère que désormais vous pourrez être notifiés rapidement d'une erreur sur votre application si vous utilisez Monolog et Slack.

Tags: slack, monolog

PgDay Paris 2016

Conférence PgDay Paris 2016

Retour sur le pgDayParis - Point de vue côté dev

Le 31 mars dernier à Paris s’est déroulée la conférence annuelle pgDay Paris.

Cet évènement organisé par la communauté française et européenne de PostgreSQL, est ouvert à tous, DBA, Développeur...

SISMIC était présente à cet événement majeur et nous partagerons notre vision de développeurs : Mathias COUTANT et Laurent BOLZER.

Historique des Bases de Données, au regard des exigences actuelles - Sébastien LARDIERE

Une première conférence très intéressante qui nous met dans le bain avec un petit retour en arrière pour nous expliquer l’évolution et les attentes des utilisateurs de bases de données.

Ce que nous retiendrons : énormément de travaux sont issus d’universités.

PostgreSQL Backup the modern ways - Magnus HAGANDER

Une conférence donnée par le président de PostgreSQL Europe, c’est quand même la classe, et en particulier sur les backups.

Après une légère introduction sur l’importance de tester ses backups (sous peine d’avoir des surprises ...), Magnus nous montre les différents moyens pour générer les backups, en passant par pg_dump (trop lent pour la restauration (et surtout aucun « PITR ») et pg_basebackup (qui est le moyen conseillé par Magnus).

Ce que nous retiendrons :
pg_basebackup doit être utilisé pour plusieurs raisons: c’est un moyen sûr qui utilise le protocole de réplication, sauvegarde sur l’ensemble de l’instance et a une gestion des erreurs.

Très important, toujours utiliser -x ou -X pour inclure xlog ...

Outils à regarder : Barman, pgBackRest.

Survivre à une migration de données de MySQL vers Postgres - Grégoire HUBERT

Migrer une base de données MySQL vers PostgreSQL n’est pas la chose la plus aisée au monde ni la plus amusante.

Grégoire commence fort et de manière assez trollesque avec "On peut migrer de MySQL à PostgreSQL en 20 min", et nous montre ensuite les différentes étapes d’une migration sans passer par un ETL (création de vues dans un db dédiée MySQL, chargement de Postgres via PgLoader, dispatch des données en SQL Postgres, tester la structure avec PgTap)

Outils qu’il faut absolument retenir:

  • PgLoader pour charger les données sous stéroïdes (gère notamment l’encoding latin1 -> utf8, stream les données via le protocole COPY qui est très rapide ...)
  • PgTap pour tester la structure.

Pause déjeuner

Il nous a été proposé un copieux buffet froid. Le repas était au top.

La pause dej a été l'occasion pour nous d'échanger avec notre ami pommiste, Grégoire HUBERT.

Quels outils de supervision pour PostgreSQL ? - Damien CLOCHARD

Cette conférence nous présentait divers outils et commandes pour visualiser et monitorer son instance PostgreSQL.

De nombreux outils y étaient présentés :

  • Nagios
  • pg_activity qui permet de visualiser en temps réel l'activité de l'instance PostgreSQL à la manière de la commande "top" pour surveiller l'activité du système
  • pgBadger analyse les logs PostgreSQL et ressort des rapports détaillés et des graphiques
  • [POWA] (http://dalibo.github.io/powa/) (Postgresql Workload Analyze) collecte les statistiques d'une base de données PostgreSQL, permet d'avoir un monitoring de l'activié de l'instance et donne des pistes d'optimisation comme la pose d'index sur certaines tables.

10 Things, an Oracle DBA should care about when moving to PostgreSQL - Ilya KOSMODEMIANSKY

Cette conférence était orientée DBA et donnait des conseils pour migrer une base de données Oracle vers PostgreSQL.

Une conférence très intéressante, mais très axée DBA et de ce fait hors de notre domaine de compétence.

Tout sur les index - Cédric VILLEMAIN

Cette conférence nous a particulièrement intéressé et donné des explications sur les différents types d'index et leur utilisation.

Bien qu'indiquée de niveau "Intermédiaire", il fallait déjà une bonne connaissance des index pour l'aprécier à sa juste valeur.

Cédric rappelle que les index ne sont pas une notion indispensable au langage SQL qui peut fonctionner sans les index. Par contre, ils ont été créés par la suite pour des questions de performance.

Des index sont créés automatiquements par le moteur SQL, comme pour les Primary Key. Dans le cas des Foreign Key, le moteur ne crée pas d'index automatiquement.

Il a ensuite donné des exemples d'utilisation des index de type BTREE, GIST, GIN et BRIN.

L'exemple qu'il a donné sur l'usage de exclude using gist était très intéressant pour gérer par exemple les conflits sur chevauchement de dates, dans le cas d'une application de planning de réservation de salle par exemple.

CREATE EXTENSION btree_gist;
CREATE TABLE DEMO (
    id serial PRIMARY KEY, 
    pseudo TEXT, 
    active_range DATERANGE, 
    EXCLUDE USING GIST (lower(pseudo) with =, active_range with &&
);

PostGeol: une (future) extension PostgreSQL pour les géologues, dans le cadre de GeolLLibre - Pierre CHEVALIER

Nous n'avons malheureusement pas pu assister à cette conférence car nous avons dû partir plus tôt pour affronter une épreuve pire qu'une migration MySQL: une grève dans les transports pour l'un, la pluie et les bouchons sur le périphérique parisien pour l'autre!

Conclusion

Les présentations de cette conférence étaient toutes très intéressantes, certaines orientées développeur, d'autres DBA, bref il y en avait pour tous les goûts !

La pluie et les grèves parisiennes, certainement orchestré par Oracle #troll, n'aurons pas eu raison du succès de ce rendez vous annuel.

Vivement l'édition 2017.

Tags: postgresql, conférence, pomm