Problème (bloquant) avec les scripts de création/maj de la base de données (sur les versions récentes de MariaDB)

[yktorza]

Bonjour,

J'ai voulu déployer l'application Esup-stage sur mon environnement de production (serveur debian 12, avec le paquet système MariaDB en version 10.11). Suite au lancement de tomcat, le déploiement est en erreur à cause de problèmes sur les scripts de création/maj de la base de données. Je précise que je fais une installation sans reprise de données depuis PStage. Les erreurs portent sur des actions qui n'aboutissent pas à cause des contraintes de clés étrangères (foreign keys). Pour info, ce problème a déjà été remonté sur la liste par Nesrine Sellami (de l'université de Nanterre) en date du 30/01/2025.

Il s'agit notamment (mais peut-être pas que) de problèmes lors des instructions ALTER TABLE dans les scripts xxx-engine-collate.sql; en effet, ces instructions échouent à cause de la présence de foreign keys. Au niveau des scripts sql, je constate qu'il y a pourtant l'instruction "SET FOREIGN_KEY_CHECKS=0;", qui est censée permettre de passer outre cette contrainte de foreign keys. Mais après avoir cherché un peu, il apparaît que depuis une certaine version de MariaDB (la 10.5 ou 10.6), cela ne suffit plus de mettre ce "SET FOREIGN_KEY_CHECKS=0;". En résumé, il n'est plus possible, sur les versions récentes de MariaDB, de faire des ALTER TABLE qui vont modifier des colonnes sur lesquelles il y a des foreign keys. La solution, c'est donc qu'il n'y ait pas de foreign keys au moment des passages des ALTER TABLE. Sauf qu'en pratique, si je veux me débloquer et pouvoir avancer sur mon déploiement en prod, c'est juste compliqué (voire impossible) d'appliquer cette solution, car les créations (et même suppressions) de foreign keys sont nombreuses et disséminées dans plusieurs scripts, aussi bien au format yaml que sql... bref rien n'a été fait de la même façon, donc j'ai laissé tomber (...à chaque fois que j'apporte des corrections, de nouvelles erreurs apparaissent)

Il faudrait impérativement revoir et homogénéiser les scripts de création/maj de la base de données, d'autant plus que là, c'est bloquant pour mon déploiement en prod, et ce sera le cas pour tous les établissements qui démarrent un nouveau déploiement avec une version récente de MariaDB.

Par ailleurs, et pour info, la "collation" utf8_general_ci est dépréciée (deprecated), il serait préférable de mettre à jour avec une qui soit plus récente (par exemple, utf8mb4_general_ci).

Cordialement,
Yaël Ktorza

[yktorza]

Pour info, grâce à l'aide de Sylvain Kieffer, j'ai pu me débloquer sur mon déploiement en prod en : ne touchant surtout pas aux scripts fournis avec Esup-stage et en créant initialement la base de données via la commande :
CREATE DATABASE estage CHARACTER SET utf8 COLLATE utf8_general_ci;
Ainsi, sachant que la base de données a déjà la bonne collation (cad la même que celle des scripts Esup-stage), je n'ai plus d'erreurs de Foreign Keys suite au lancement de tomcat.
C'est cette solution qu'il faut donc appliquer dans le cas où on démarre avec une bdd vierge (sans reprise de données depuis PStage).
Bien entendu, c'est en attendant d'avoir une mise à jour (indispensable) des scripts fournis avec Esup-stage et qui doivent prendre en compte le fait qu'il n'est plus possible de faire des ALTER TABLE en présence de Foreign Keys (même si on met des "SET FOREIGN_KEY_CHECKS=0;"), donc je maintiens cette issue.
Concernant les établissements qui font une reprise de données depuis PStage, là, c'est beaucoup plus compliqué... il n'y a pas de solution simple à part avoir un script qui irait retirer toutes les Foreign Keys, mettre la bonne collation sur les tables et la bdd, puis remettre toutes les Foreign Keys (script qui serait à lancer après l'import du dump de PStage dans la bdd esup-stage, et encore, sans certitude que cela soit suffisant). Compte tenu de la complexité de cette solution, on peut considérer que le problème est bloquant pour ceux qui font/feront une reprise de données depuis PStage.