-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problème (bloquant) avec les scripts de création/maj de la base de données (sur les versions récentes de MariaDB) #289
Comments
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 : |
Pour éviter les erreurs de Foreign Keys et de collation lors du déploiement d'Esup-Stage sur une base vide, suivez ces étapes avant d’exécuter les scripts Liquibase : CREATE DATABASE estage CHARACTER SET utf8 COLLATE utf8_general_ci; Cette solution garantit une collation homogène avec les scripts Liquibase et évite les conflits sur les versions récentes de MariaDB (10.5+). |
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
The text was updated successfully, but these errors were encountered: