Agate @agate@eldritch.cafe

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.

Ç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.)

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é.

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.

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

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

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 😁

du coup là ils m'envoient des articles scientifiques sur le sujet et je leur fais découvrir les vidéos de Trans Voice Lessons :D

Ah ben du coup mes collègues l'ont fait aussi, on s'est retrouvé à parler de féminisation de la voix c'était génial.

Je les aime, ils sont vraiment trop chouettes. Ils m'ont proposé de voir s'ils pouvaient développer des outils de transformation de la voix pour les transitions.

Et ils ont repéré un mégenrage potentiel pendant un meeting avec un client et m'ont proposé d'eux mêmes de recadrer le truc et de faire bloc les fois suivantes.

J'ai trop de chance.

J'avais écrit ce poème pour une amie de la clinique, fan de JUL. Il me fait rire alors je le ressors.

D'or et de platine
Heloïse luît
Pas une bombe latine
Mais un lac de nuit

Apaisant et calme
Ses reflets d'or
Emoussent les lames
Ouais : chaleur

Et je lance avec `docker run --rm -v /home/user/migration.pgloader:/load dimitri/pgloader:ccl.latest pgloader -v load`

Hop, ça tourne, c'est fini, on passe à autre chose.

Sur la migration elle-même, j'utilise comme prévu l'excellent https://github.com/dimitri/pgloader/.

```
load database
from mysql://user:pass@127.0.0.1/mydb
into postgresql://user:pass@127.0.0.1/mydb
WITH include drop, create tables, quote identifiers,
create indexes, foreign keys, workers = 8, concurrency = 3,
rows per range = 50000
ALTER SCHEMA 'mydb' RENAME TO 'public'
SET timezone to 'Europe/Paris';
```

dans un fichier `migration.pgloader`

Et je suis sûre que je suis pas au bout de mes (bonnes) surprises du même genre ;)

Deux trucs qui illustrent la différence pour moi assez monstrueuse entre MySQL 8 et PostgreSQL 13 :

- La base migrée sous PG, même structure, même nombre de ligne, prend presque 2x moins d'espace (6.6GB sur le disque, avec les index). 11.7GB sur MySQL 8. Impressionnant
- Sur MySQL un `SELECT count(*) FROM table` de notre table la plus importante (1.3 millions de lignes) prenait plusieurs minutes, voire n'aboutissait pas. Ça tourne en quelques secondes sur PG

Dont migration de MySQL vers PostgreSQL arrêtée mercredi prochain, au soir.

Je le sens bien, j'ai déjà fait une migration de test, notre BDD de 11GB migre en 13 minutes montre en main et son volume sera similaire la semaine prochaine.

J'ai a priori trouvé et réglé d'éventuels soucis de timezones.

Ma check-list pré-migration est presque cochée partout !