Re: [Dolibarr-dev] Migration 2.1.0-2.2.0 - Problème foreign key sur llx_societe.idp

[Yannick Warnier]

Le lundi 07 janvier 2008 à 02:06 +0100, Yannick Warnier a écrit :
> Oui oui, d'office. C'est ce dont je venais de me rendre compte (que
> phpMyAdmin ne les affiche pas) et je suis occupé à chercher dans le dump
> (on a fait le même raisonnement).
> 
> Pour l'info, notre install est en effet assez vieille et je retrouve les
> lignes suivantes (je les mets en entier, c'est la meilleure façon de
> voir quelle table et quelle clef):
> 
> 
> ALTER TABLE `llx_fichinter`
>   ADD CONSTRAINT `fichinter_fk_soc_idp` FOREIGN KEY (`fk_soc`)
> REFERENCES `llx_societe` (`idp`);
> 
> ALTER TABLE `llx_socpeople`
>   ADD CONSTRAINT `socpeople_fk_soc_idp` FOREIGN KEY (`fk_soc`)
> REFERENCES `llx_societe` (`idp`);
> 
> Voilà, c'était tout. Il a donc suffi d'un:
> ALTER TABLE llx_fichinter DROP FOREIGN KEY fichinter_fk_soc_idp;
> ALTER TABLE llx_socpeople DROP FOREIGN KEY socpeople_fk_soc_idp;
> 
> puis de reprocéder à l'upgrade pour que ça s'arrange.
> 
> Tiens, dans le fond, est-ce qu'on peut appliquer le script d'upgrade
> plusieurs fois d'affilée sans trop de dégâts? Un rapide survol semble me
> faire comprendre que les insertions se font toujours avec des IDs
> prédéfinis, donc normalement ça devrait passer, mais je me demande si
> c'est fait pour ou si c'est juste un hasard?


Bien que je ne pense pas que ce soit vraiment important ni endommageant,
j'ai eu une espèce de boucle MySQL (un SLEEP au niveau du serveur MySQL)
pour la migration d'un des portails, dans upgrade2.php, au moment de
migrer les données de commandes clients. Pas bien compris pourquoi
(d'autant qu'il n'y a, à priori, aucune commande client), mais je
signale le problème au cas où on en rediscuterait plus tard.
C'était donc pour une migration de 2.1.0(beta) vers 2.2.0.

Le reste s'est bien passé (sur une dizaine de portails deux erreurs
bloquantes et une erreur non-bloquante, ça va encore).

Yannick