Incident MAJ 13.0.0 > 13.0.2

mrj · Mai 18, 2021, 8:30

Bonsoir à tous,

Nos MAJ se passent bien depuis une éternité, et puis ce soir l’update vers 13.0.2 a planté

Je teste la MAJ sur mon env de recette et :

tout est au vert pour les pré-requis,
« Mise à jour 12.0.* ou 13.0.0 → 13.0.* » est dispo, tout semble bien parti.

Je lance et là impossible de migrer la db !

Seule différence connue à ce jour, le passage forcé vers MySQL 5.6.51 imposé sur le sql privé d’OVH.

En parcourant le forum, je trouve des solutions miracle ou parfois risquées (ignorer l’erreur)

Les erreurs :

Erreur DB_ERROR_CANNOT_ADD_FOREIGN_KEY_CONSTRAINT: ALTER TABLE llx_recruitment_recruitmentjobposition ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_recruiter FOREIGN KEY (fk_user_recruiter) REFERENCES llx_user(rowid);
Cannot add foreign key constraint

Erreur DB_ERROR_CANNOT_ADD_FOREIGN_KEY_CONSTRAINT: ALTER TABLE llx_recruitment_recruitmentjobposition ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_supervisor FOREIGN KEY (fk_user_supervisor) REFERENCES llx_user(rowid);
Cannot add foreign key constraint

Erreur DB_ERROR_CANNOT_ADD_FOREIGN_KEY_CONSTRAINT: ALTER TABLE llx_recruitment_recruitmentjobposition ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_establishment FOREIGN KEY (fk_establishment) REFERENCES llx_establishment(rowid);
Cannot add foreign key constraint

Erreur DB_ERROR_CANNOT_ADD_FOREIGN_KEY_CONSTRAINT: ALTER TABLE llx_recruitment_recruitmentjobposition ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_creat FOREIGN KEY (fk_user_creat) REFERENCES llx_user(rowid);
Cannot add foreign key constraint

Erreur DB_ERROR_CANNOT_ADD_FOREIGN_KEY_CONSTRAINT: ALTER TABLE llx_recruitment_recruitmentcandidature ADD CONSTRAINT llx_recruitment_recruitmentcandidature_fk_user_creat FOREIGN KEY (fk_user_creat) REFERENCES llx_user(rowid);
Cannot add foreign key constraint

Merci par avance pour votre aide

jtraulle · Mai 19, 2021, 6:29

Bonjour,

Puisqu’on parle ici de contraintes d’intégrité fonctionnelle de type « clés étrangères », voici quelques pistes :

s’assurer que le type des colonnes clés primaires et des clés étrangères à créer sont identiques (même type, même taille)
s’assurer que les données actuellement en bases satisfont actuellement ces contraintes (pas possible de placer les clés étrangères si les éléments référencés n’existent pas dans la table primaire par exemple).

ALTER TABLE llx_recruitment_recruitmentjobposition 
ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_recruiter 
FOREIGN KEY (fk_user_recruiter) 
REFERENCES llx_user(rowid);

ALTER TABLE llx_recruitment_recruitmentjobposition 
ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_supervisor 
FOREIGN KEY (fk_user_supervisor)
REFERENCES llx_user(rowid);

ALTER TABLE llx_recruitment_recruitmentjobposition 
ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_establishment
FOREIGN KEY (fk_establishment)
REFERENCES llx_establishment(rowid);

ALTER TABLE llx_recruitment_recruitmentjobposition
ADD CONSTRAINT llx_recruitment_recruitmentjobposition_fk_user_creat
FOREIGN KEY (fk_user_creat)
REFERENCES llx_user(rowid);

Donc vérifier que la colonne rowid de la table llx_user et les colonnes fk_user_recruiter, fk_user_recruiter, fk_user_creat de la table llx_recruitment_recruitmentjobposition sont bien de même type et que les valeurs éventuellement déjà référencées existent bien dans llx_user.

Pareil pour fk_establishment de llx_recruitment_recruitmentjobposition qui référence rowid dans llx_establishment

mrj · Mai 20, 2021, 5:18

Bonjour et merci pour cette réponse @jtraulle

J’ai continué de fouiller ce sujet :

les tables llx_recruitment* semblent provenir d’un module de recrutement apparu à priori dans la v13 d’après le dépôt de code.
Le module n’apparait pas dans les modules Dolibarr sur notre prod (v.13.0.0)

Cette colonne n’aurait pas dûe être mise à jour au même moment que Dolibarr ?

Je ne sais pas quoi modifier pour faire correspondre les champs.
Peut-être passer rowid des tables llx_establishment et llx_user en integer ? Auquel cas je vois pas bien la différence ^^

Les tables llx_user et llx_establishment, dans la db avant MAJ :

CREATE TABLE `llx_establishment` (
    `rowid` int(11) NOT NULL AUTO_INCREMENT,
     [...]
    PRIMARY KEY (`rowid`)
) ENGINE = MyISAM DEFAULT CHARSET = latin1


CREATE TABLE `llx_user` (
    `rowid` INT(11) NOT NULL auto_increment,
    [...] 
    PRIMARY key (`rowid`),
    UNIQUE KEY `uk_user_login` (`login`, `entity`),
    UNIQUE KEY `uk_user_fk_socpeople` (`fk_socpeople`),
    UNIQUE KEY `uk_user_fk_member` (`fk_member`),
    KEY `idx_user_api_key` (`api_key`),
    KEY `idx_user_fk_societe` (`fk_soc`)
) engine = myisam auto_increment = 27 DEFAULT charset = latin1

Le create table Dolibarr :

CREATE TABLE llx_recruitment_recruitmentjobposition(
    rowid integer AUTO_INCREMENT PRIMARY KEY NOT NULL,
    ref varchar(128) DEFAULT '(PROV)' NOT NULL,
    entity INTEGER DEFAULT 1 NOT NULL,
    label varchar(255) NOT NULL,
    qty integer DEFAULT 1 NOT NULL,
    fk_soc integer,
    fk_project integer,
    fk_user_recruiter integer,
    fk_user_supervisor integer,
    fk_establishment integer,
    date_planned date,
    remuneration_suggested varchar(255),
    description text,
    note_public text,
    note_private text,
    date_creation datetime NOT NULL,
    tms timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    fk_user_creat integer NOT NULL,
    fk_user_modif integer,
    last_main_doc varchar(255),
    import_key varchar(14),
    model_pdf varchar(255),
    status smallint NOT NULL
) ENGINE = innodb;

En bonus, j’ai découvert que si j’exporte ma db de prod vers un docker local en mysql5.6 j’ai aussi le même genre d’erreur :

ALTER TABLE `llx_categorie_account`
ADD CONSTRAINT `fk_categorie_account_categorie_rowid` FOREIGN KEY (`fk_categorie`) REFERENCES `llx_categorie` (`rowid`),
ADD CONSTRAINT `fk_categorie_account_fk_account` FOREIGN KEY (`fk_account`) REFERENCES `llx_bank_account` (`rowid`);

mrj · Mai 20, 2021, 6:18

Je pense avoir trouvé la solution à ce problème grace à la doc suivante :

Il s’avère, pour une raison que j’ignore, que certaines tables sont en MyISAM au lieu d’InnodB. Il suffit de passer les tables concernées avec le bon engine pour que les FOREIGN KEY soient correctement créées.

Nous faisons les MAJ au fil de l’eau, et il semble que l’une des MAJ ait omis de changer ça !

mrj · Mai 20, 2021, 8:08

Migration de la recette sans incident après avoir exécuté ces requêtes :

ALTER TABLE llx_user ENGINE=INNODB;
ALTER TABLE llx_establishment ENGINE=INNODB;
ALTER TABLE llx_bank_account ENGINE=INNODB;
ALTER TABLE llx_categorie ENGINE=INNODB;

Production MAJ aussi.

Comme quoi RTFM est toujours d’actualité ^^

Reste plus qu’à vérifier si une des MAJ Dolibarr a loupé l’update de ces tables

Bonne soirée \o/

Arre · Mai 21, 2021, 10:12

Salut @mrj,

j’ai du mal à comprendre comment ça a pu arriver : j’ai une instance test « témoin » que je migre de version en version depuis la V3 (y compris les mineures quand j’y pense ^^) et rien ne s’est jamais mal passé.

J’imagine un scénario : tu aurais migré sur une version en cours de dev (imaginons une « V9 stable » → « V10 dev ») au moment où des choses en « V10 dev » étaient développées et pas stable.

Ta V10 « dev » : tu l’as écrasé avec la V10 « stable » une fois qu’elle est sortie.
Sauf que les scripts de migrations V9x ->V10 ne se sont pas exécutés… vu que tu était déjà en V10. (du coup une partie des maj ne sont pas passées)

ou alors …

tu as migré entre 2 serveurs entre 2 versions bancales …

Ca te parle ce genre de manip ?

mrj · Mai 21, 2021, 10:39

Les MAJ ne sont pas toujours faites avec le plus grand suivi, il est même arrivé qu’on saute une majeure.

Je travaille toujours avec un espace de recette séparé de la prod, sur lequel la MAJ est testée. Je réplique souvent (pas toujours) ma prod vers la recette si elles ne sont pas sync avant une MAJ.

Cette installation n’a jamais été migrée de serveur, elle date de mi-2014.

Par contre ce scénario me dit vaguement quelque chose :

J’imagine un scénario : tu aurais migré sur une version en cours de dev (imaginons une « V9 stable » → « V10 dev ») au moment où des choses en « V10 dev » étaient développées et pas stable.

Ta V10 « dev » : tu l’as écrasé avec la V10 « stable » une fois qu’elle est sortie.
Sauf que les scripts de migrations V9x ->V10 ne se sont pas exécutés… vu que tu était déjà en V10. (du coup une partie des maj ne sont pas passées)