Bon, la migration approche, et j'ai spotté ce matin un souci qui aurait cassé toute la prod le jour de la migration.

Pgloader avait bien identifié la primary key de chaque table mais il n'avait pas créé les séquence postgresql correspondantes.

La séquence c'est le truc que la BDD garde en tête pour pouvoir attribuer un ID unique à chaque nouvel objet.

Et du coup, c'était impossible d'insérer de nouveaux objets en base 😁

Heureusement, ça a pris deux lignes à changer dans le fichier pgloader, basiquement:

CAST
type int with extra auto_increment to serial drop typemod keep default keep not null

J'ai un peu galéré a trouver ça par contre u.u

Du coup ça me semble pas mal pour la migration, j'ai l'impression que ça va bien se passer (bien sûr le jour J je trouverai un truc qui casse tout mais bon, c'est la loi de Murphy ça).

Et j'attaque un autre chantier, important aussi, migrer sur un système de… migrations, justement :D

Actuellement, toutes les modifs BDD sont faites directement en prod, pas testées, et il est de fait assez dur de reproduire la base de prod (avec ses index, triggers, contraintes, etc.) pour travailler localement ou pour un environnement de staging par exemple.

Bien sur, on pourrait faire un dump de la structure de la prod chaque fois qu'on en a besoin mais bon, c'est pas idéal du tout.

Donc là je prends une approche différente, et je fais en sorte que toute la structure de la base de données (tables, colonnes, index, triggers, etc.) soit stockée et versionnée dans un dépôt.

J'ai hésité entre https://alembic.sqlalchemy.org/ et l'outil fourni par Django pour gérer ça, mais finalement je suis parti sur celui de Django, vu que je le connais bien, c'est autant de temps de gagné.

Ça permet aussi d'avoir des tests unitaires (est-ce que mes migrations tournent sur une base vierge) pour ce qui concerne la BDD, des rollbacks (annuler une migration qui a mal tourné), et tout simplement de discuter et reviewer les changements dans un workflow de développement plus serein (Gitlab, review, merge requests, etc.)

Après clairement, ça reste une solution meilleure mais pas forcément idéale, vu que je suis DBA de fait, pas de formation.

A PeopleDoc l'équipe gérait ça sans ORM, avec du SQL brut et ils unittestaient tout, mais j'ai pas le niveau pour ça.

Par contre si on embauche un·e vrai DBA un jour, je lui aurait au moins facilité la tâche pour reprendre le gouzi et c'est satisfaisant.

Y'a tellement de choses que j'aimerait bien apprendre en DBA, principalement les vues, les triggers et les fonctions, même si j'ai manipulé très basiquement, c'est que la surface et quand je vois ce que mes ex-collègues arrivaient à faire avec, c'était juste impressionnant…

@agate C'est quelque chose que je connais un peu, sans pour autant dire que je maîtrise, donc si t'as besoin d'aide hésite pas !

@agate

J'aime beaucoup BEAUCOUP les triggers