problème upgrade docker

[carlou]

Bonjour,

Je tente de faire un upgrade de creme sous docker et je rencontre un soucis:

Passage de creme-demo: latest (2.3RC1 - 2.3.6) en creme-demo:2.4.6

-> Sur le serveur test avec une V2.3.6 fraiche, l'upgrade c'est fait sans aucune difficulté.

-> Sur le serveur de prod j'ai le message suivant : django.db.utils.OperationalError: (1050, "Table 'creme_core_relationtype_subject_forbidden_properties' already exists")
A savoir que la bdd est la depuis la V2.1 minimum.

j'ai regardé dans la bdd existante et cette table n'existe pas.

Une piste?
Merci d'avance!

[genglert]

Bonjour,

tout d'abord il semble que vous utilisiez l'image docker que nous fournissons à des fins de démo (comme son nom l'indique). C'est à dire destinée aux personnes qui cherchent un CRM, testent/comparent plusieurs logiciels et donc pour lesquelles il est intéressant de pouvoir rapidement se faire une idée des fonctionnalités disponibles (il y a notre démo en ligne, mais certaines fonctionnalités y sont désactivées). Donc elle n'a pas été conçue pour être déployée en production.

Vous parlez d'une base qui date d'au moins Creme 2.1, mais nous ne fournissons d'image Docker que depuis Creme 2.3. Du coup je présume que vous savez installer avec la méthode conseillée (virtualenv + pip + creme migrate etc... ; ça n'empêche pas de conteneurisé évidemment). Notez que dans les tutoriels j'explique aussi comment migrer depuis une version précédente (pour 2.4 par exemple: https://www.cremecrm.com/forum/showthread.php?tid=229 )

Si django dit que la table existe et que vous ne la voyez pas, vous ne regardez peut-être pas la bonne base. Ou alors votre historique de migration est cassé (ex: vous avez rollback sur une ancienne version de creme avant la migration ? sauté deux versions de creme ? etc...). Vous pouvez regarder la table "django_migrations", et éventuellement pour comparer avec les fichiers de migration (dans les répertoires migrations/ des apps) ; la table contient la date d'application de la migration, ce qui peut aider. Pour info la table donc vous me parlez est effectivement une nouveauté de Creme 2.4.

En dernier recours la commande "migrate" permet de "faker" une migration (c'est à dire l'inscrire dans la table des migrations passées, mais sans l'exécuter, parce que par exemple ce qu'elle contient a de fait déjà été exécuté).

Bon courage pour la suite et bon week-end !

[carlou]

Bonjour, merci pour la réponse,

En gros de tête je crois qu'on a fait :
2.1 vers 2.2 en virtualenv
ensuite docker, migration vers 2.3, puis mise à jour vers 2.3.6
Jusque là tout fonctionne a merveille depuis 1 an (avec un docker-compose.yml adapté)

Je viens de tester sur un autre serveur, avec la bdd de prod et j'ai le même soucis.

edit: si je supprime en direct la table, la migration la recrée et ensuite j'ai :
django.db.utils.OperationalError: (3780, "Referencing column 'relationtype_id' and referenced column 'id' in foreign key constraint 'creme_core_relationt_relationtype_id_597a4664_fk_creme_cor' are incompatible.")

  Applying creme_core.0111_v2_4__rtype_forbidden_properties...


je vais investiguer plus avec vos information.
Bonne soirée!

[genglert]

Si vous utilisez MySQL/MariaDB, la gestion des contraintes est encore très perfectible malheureusement (genre les contraintes relatives à une table qui sont parfois conservées meme quand ladite table est supprimée...)

[carlou]

Si vous utilisez MySQL/MariaDB, la gestion des contraintes est encore très perfectible malheureusement (genre les contraintes relatives à une table qui sont parfois conservées meme quand ladite table est supprimée...)

c'est une mysql oui

[carlou]

Bonjour,

Après beaucoup beaucoup de recherches et de tests, j'ai trouvé comment corriger le problème.
En gros, il y a eu un mélange entre le v2.3 et la v2.4 lors de la mise à jour qui a buggée pour je ne sais quelle raison.
je passe toutes les opérations que j'ai essayé de faire pour résoudre le soucis (comparatif tables v2.3/v2.4, modifs à la main etc)
et en fait la solution est simple :

il suffit dans mysql de rajouter la commande :

Code :

INSERT INTO `django_migrations` (`id`, `app`, `name`, `applied`) VALUES
(367, 'creme_core', '0111_v2_4__rtype_forbidden_properties',  '2023-09-08 13:16:36.612932')

avec l'id adapté en fonction de sa bdd

cela m'a fait ensuite pareil pour 0114_v2_4__unique_user_email et tout le reste de la mise à jour c'est effectué.

Je poste la solution au cas ou quelqu'un aurait le même genre de soucis

Bonne journée!

[Prilux]

Salut,

Merci d'avoir pris le temps de partager la solution, ça va clairement dépanner quelqu'un d'autre un jour !

Petit conseil pour la prochaine fois si ça devait re-arriver : plutôt que l'INSERT à la main dans `django_migrations`, autant utiliser directement `migrate --fake`, ça fait la même chose mais sans risquer une erreur bête sur l'id ou le format de la date :

creme migrate creme_core 0111_v2_4__rtype_forbidden_properties --fake --settings=my_project24.settings

Et dans ce genre de manip, je fais toujours un petit `mysqldump` avant de toucher à la table des migrations, juste au cas où — une correction pas tout à fait juste peut créer des soucis ailleurs qui sont ensuite bien plus galères à retrouver.

Pour la cause du bug en lui-même, ça sent le grand classique : un conteneur qui redémarre avec une image mise à jour avant que les migrations de l'ancienne version aient fini de tourner, ou un rollback de conteneur sans rollback de la base derrière. Ça vaut peut-être le coup de rejeter un œil à tes logs de déploiement autour de ta bascule 2.3 → 2.4, pour éviter la surprise à la prochaine grosse mise à jour. Et comme le disait genglert, vu que `creme-demo` n'est pas pensée pour la prod, à terme ça vaut le coup de passer par une install virtualenv + pip pour avoir la main plus finement sur les migrations.

Bon courage pour la suite !