Development #74926: migration ultra lente en recette (lié à Django 3.2 ?) - Combo - Redmine Entr’ouvert

Development #74926

migration ultra lente en recette (lié à Django 3.2 ?)

Ajouté par Valentin Deniaud il y a environ un an. Mis à jour il y a environ un an.

Statut:

Fermé

Priorité:

Normal

Assigné à:

Valentin Deniaud

Version cible:

Début:

28 février 2023

Echéance:

% réalisé:

Temps estimé:

Patch proposed:

Non

Planning:

Non

Description

Lignes prises au hasard :

févr. 28 12:13:30 combo combo-manage[3093]: notifications.Notification: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
févr. 28 12:13:30 combo combo-manage[3093]: pwa.PwaNavigationEntry: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
févr. 28 12:13:30 combo combo-manage[3093]: wcs.WcsCurrentFormsCell: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.

Aussi des warnings dépréciations JSONField qui seront sûrement résolus par un coup de django-upgrade.

~~Pour chaque modèle ça semble créer une clé primaire (?), résultat chaque tenant prend 5 minutes à être migré.~~

Demandes liées

Historique

Mis à jour par Valentin Deniaud il y a environ un an

Description mis à jour (diff)

Bon j'ai mal interprété ce que me disait Thomas, en fait chaque tenant prend 5/10 secondes mais comme il y en a 470 ça fait une migration d'une heure.

Et la migration ajoute bien une colonne donc c'est normal que ça prenne un peu de temps.

Est-ce que la génération de ces warning ralentit beaucoup la migration, ou ça a toujours pris une heure d'ajouter une colonne sur combo en recette ?

Mis à jour par Thomas Noël il y a environ un an

Valentin Deniaud a écrit :

Bon j'ai mal interprété ce que me disait Thomas

Désolé, j'ai un peu exagéré, effectivement ce n'est pas 5 minutes mais 5 secondes.

Sinon, faut tester sur un publik-devinst en django 3.2 pour voir si ces opérations de vérifications mangent du temps.

Mis à jour par Valentin Deniaud il y a environ un an

Thomas Noël a écrit :

Sinon, faut tester sur un publik-devinst en django 3.2 pour voir si ces opérations de vérifications mangent du temps.

Ouep en local ces vérification prennent également ~5s par tenant (et le SQL 0.03s). Ça prenait 1s en 2.2.

L'augmentation est fonction du nombre de modèle, donc on a un problème ici et dans passerelle (encore pire là bas, ~10s).

Corriger les warnings ne change rien. Le correctif c'est de passer --skip-checks à migrate_schemas, et hop on retrouve des durées normales.

Je vais faire (demain) un patch sur le script d'installation debian pour passer cette option (puis je ferai le même commit partout sans ticket, as usual).