Mise à jour Ecto impossible - souci lié aux migrations

[thbar]

"Yak-shaving ahead"

Voilà la pelote de laine:

• je travaillais sur les MAJ techniques ici [WIP] Mises à jour techniques (Elixir 1.17.3, OTP 27.1) #4216
• quand à un moment, je me rends compte qu'il est souhaitable de mettre à jour Ecto (notamment pour dégager connection qui n'est plus maintenu ; la dépendance disparaît en mettant à jour postgrex)
• je tente ma chance ici Mises à jour techniques relatives à Ecto #4347
• quand soudainement, une migration de 2022 se met à planter
• je regarde de plus près, et comprends que la syntaxe n'a, si je lis bien, jamais été correcte (et que la mise à jour d'Ecto réduit une souplesse sur ce qui était ignoré de façon silencieuse avant):

transport-site/apps/transport/priv/repo/migrations/20221206135302_data_import_delete.exs

Lines 21 to 24 in 01db066

	references(:data_import,
	on_delete: :delete_all,
	from: references(:data_import, on_delete: :nothing)
	)

• En effet, references ne prend pas d'option from:, c'est plutôt à mettre si je lis bien sur modify.
• On peut tenter de corriger la syntaxe:

      alter table(tbl) do
        modify(
          :data_import_id,
          references(:data_import, on_delete: :delete_all),
          from: references(:data_import, on_delete: :nothing)
        )
      end

• Toutefois après avoir fait ça, un autre problème apparaît, qui était probablement lui aussi pré-existant: ** (Postgrex.Error) ERROR 42704 (undefined_object) constraint "gtfs_stops_data_import_id_fkey" of relation "gtfs_stops" does not exist

Mais quoi faire ?

À ce stade on peut penser à deux stratégies:

1. essayer de rétro-corriger cette migration, en respectant l'état final attendu
2. ou "Squasher les migrations Ecto" #3596, qui nous pendait au nez de toute façon à un moment, avec actuellement pas moins de 193 migrations

Traiter le point 1 sera plus rapide si on arrive à corriger ça proprement.

Traiter le point 2 se fait bien (https://github.com/fly-apps/safe-ecto-migrations?tab=readme-ov-file#squashing-migrations) toutefois dans notre cas, des données "référentielles" ont été injectées par endroit via les migrations, il y a des triggers etc, donc il faudra s'assurer que le dump est "propre" et suffisamment proche de la production pour qu'on ne pense pas en dév, que les choses marchent, pendant qu'elles échoueront en production.

Et ça serait sûrement le bon moment d'introduire un seeds.exs pour charger les données automatiquement en dev/test avec ce référentiel (et ne conserver que de la structure dans les migrations).

[AntoineAugusti]

Je prends en charge ce ticket et propose de suivre uniquement le 1) pour le moment, les autres tâches demandant bien plus de travail, il faudra qu'elles soient évaluées/planifiées.

Je regarde donc pour réparer cette migration.

[thbar]

Merci @AntoineAugusti !