Boulot, DBA stuff
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 😁
Boulot, DBA stuff
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
Boulot, DBA stuff
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
Boulot, DBA stuff
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.
Boulot, DBA stuff
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é.
Boulot, DBA stuff
Ç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.)
Boulot, DBA stuff
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.
Boulot, DBA stuff
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…
Boulot, DBA stuff
J'aime beaucoup BEAUCOUP les triggers
Boulot, DBA stuff
@agate On m'a bridée dans mon boulot parce que je voulais utiliser les triggers pour des trucs et on m'a dit que non il fallait faire ça dans le code de l'appli ;_;
Boulot, DBA stuff
@Nocta ah ben je viendrai surement te faire coucou pour ça alors ! Moi aussi j'avais tendance à faire ça dans l'applicatif avant mais je fais plus confiance à la DB qu'à mon code maintenant :D
Boulot, DBA stuff
@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 !