Bonjour,
sur debian 9 j'essaye de créer la base de données avec le script d'init du package.
VOici l'erreur :
[code]root@squash:/usr/share/dbconfig-common/data/squash-tm/install# mysql -u squashtm --ppassword -h mariadb squashtm < mysql
ERROR 1832 (HY000) at line 770: Cannot change column 'ATTACHMENT_LIST_ID': used in a foreign key constraint 'fk_attachment_att_list'[/code]
La version du package est :
1.19.0.RELEASE-8
Es-ce un 'bug' connu ?
Bug script d'init mysql
Bug script d'init mysql
Je vais m'auto répondre :
https://ci.squashtest.org/mantis/view.php?id=7213
La mise à jour de debian 9 avec la version 10.2 de MariaDB résoud bien le problème.
Il serait utile de mettre à jour le wiki.
https://ci.squashtest.org/mantis/view.php?id=7213
La mise à jour de debian 9 avec la version 10.2 de MariaDB résoud bien le problème.
Il serait utile de mettre à jour le wiki.
Bug script d'init mysql
Bonjour,
le [url=https://sites.google.com/a/henix.fr/wik ... requisites]wiki[/url] est déjà à jour de cette information ;)
[quote]Regarding MariaDB: we do not support it officialy yet. MariaDB will be supported at the beginning of 2019. We have not met any incompatibilities with the 10.2 version yet, but MariaDB 10.1 is not compatible with Squash TM.[/quote]
le [url=https://sites.google.com/a/henix.fr/wik ... requisites]wiki[/url] est déjà à jour de cette information ;)
[quote]Regarding MariaDB: we do not support it officialy yet. MariaDB will be supported at the beginning of 2019. We have not met any incompatibilities with the 10.2 version yet, but MariaDB 10.1 is not compatible with Squash TM.[/quote]
Bug script d'init mysql
Oups :)
Merci de me corriger !
Je vais donc essayer avec du postgres.
Merci de me corriger !
Je vais donc essayer avec du postgres.
Bug script d'init mysql
Re-bonjour,
ce n'est pas forcément nécessaire, les SGBD actuellement supportés sont:
- postgresql 9.6+
- mysql 5.5 ou mysql 5.7+
- mariadb 10.2
Si vous avez votre base sur mariadb 10.2 (installation via le dépôt apt fourni par la communauté mariadb par exemple), vous pouvez conserver cette base sans problème (nous utilisons cette configuration sur plusieurs instances en production).
ce n'est pas forcément nécessaire, les SGBD actuellement supportés sont:
- postgresql 9.6+
- mysql 5.5 ou mysql 5.7+
- mariadb 10.2
Si vous avez votre base sur mariadb 10.2 (installation via le dépôt apt fourni par la communauté mariadb par exemple), vous pouvez conserver cette base sans problème (nous utilisons cette configuration sur plusieurs instances en production).
Bug script d'init mysql
Effectivement,
malheureusement notre environnement est sur du mariadb 10.1 le moteur de base est mutualisé pour plusieurs applications. Donc upgrader nécessite de revalider toutes nos applications, bref c'est un gros chantier ;)
J'ai pu voir dans un poste :
[code]
SET FOREIGN_KEY_CHECKS=0;
et le mettre à la fin :
SET FOREIGN_KEY_CHECKS=1;
Cela désactivera le contrôle des contraintes de clé étrangère le temps de passer le script d'installation de la base. [/code]
Mais cette solution ne me semble pas raisonnable je ne sais pas ce que ça peut avoir comme impact sur l'application.
malheureusement notre environnement est sur du mariadb 10.1 le moteur de base est mutualisé pour plusieurs applications. Donc upgrader nécessite de revalider toutes nos applications, bref c'est un gros chantier ;)
J'ai pu voir dans un poste :
[code]
SET FOREIGN_KEY_CHECKS=0;
et le mettre à la fin :
SET FOREIGN_KEY_CHECKS=1;
Cela désactivera le contrôle des contraintes de clé étrangère le temps de passer le script d'installation de la base. [/code]
Mais cette solution ne me semble pas raisonnable je ne sais pas ce que ça peut avoir comme impact sur l'application.
Bug script d'init mysql
Bonjour,
a priori aucun impact sur l'application, il s'agit simplement de désactiver les contrôles des FK durant l'initialisation de la base, mais ces FK sont tout de mêmes créées. Et s'agissant du script d'initialisation, il n'y a normalement pas de FK qui soit en violation avec ces contraintes.
a priori aucun impact sur l'application, il s'agit simplement de désactiver les contrôles des FK durant l'initialisation de la base, mais ces FK sont tout de mêmes créées. Et s'agissant du script d'initialisation, il n'y a normalement pas de FK qui soit en violation avec ces contraintes.