Projet

Général

Profil

Development #29522

accélération migrate_schemas

Ajouté par Frédéric Péters il y a 2 mois. Mis à jour il y a 26 jours.

Statut:
Solution déployée
Priorité:
Normal
Assigné à:
Catégorie:
-
Début:
07 jan. 2019
Echéance:
% réalisé:

0%

Patch proposed:
Oui

Description

Indépendamment d'une parallélisation (#23045), il pourrait peut-être y avoir optimisation,

  • faire les migrations du schéma "public"
  • pour chaque tenant, si le contenu de la table django_migrations correspond au contenu du schéma "public", zapper le tenant
    • éventuellement, si ça ne correspond pas, lancer les migrations en précisant uniquement les applications où une différence a été notée. (je n'ai pas mesuré, je garderais ça pour plus tard)

0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch Voir (2,56 ko) Frédéric Péters, 07 jan. 2019 14:12

0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch Voir (3,01 ko) Frédéric Péters, 07 jan. 2019 14:41

0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch Voir (3,17 ko) Frédéric Péters, 21 fév. 2019 08:26

Révisions associées

Révision 37f7dff9 (diff)
Ajouté par Frédéric Péters il y a 26 jours

multitenant: skip tenants where all migrations are applied (#29522)

Historique

#1 Mis à jour par Frédéric Péters il y a 2 mois

#2 Mis à jour par Frédéric Péters il y a 2 mois

  • Statut changé de Solution proposée à En cours
  • Patch proposed changé de Oui à Non

Oui mais non, ça choppe des migrations qui n'existent plus (artefact du foutoir dans ma db locale, sûr, mais je vais quand même voir pour considérer uniquement les migrations réelles).

#3 Mis à jour par Thomas Noël il y a 2 mois

A noter qu'en théorie, le schéma "public" ne contient pas forcément les mêmes apps que ceux des tenants (INSTALLED_APPS/SHARED_APPS/TENANTS_APP).

Il faudrait plutôt considérer "les migrations du premier tenant qui a été migré".

#4 Mis à jour par Frédéric Péters il y a 2 mois

A noter qu'en théorie, le schéma "public" ne contient pas forcément les mêmes apps que ceux des tenants (INSTALLED_APPS/SHARED_APPS/TENANTS_APP).

La table django_migrations du schéma public liste également les migrations concernant les TENANT_APPS.

Du coup on peut se baser dessus.

(mais aussi, considérons uniquement la pratique (?)).

#5 Mis à jour par Frédéric Péters il y a 26 jours

Modification pour ne pas toucher au comportement quand --fake est passé.

#6 Mis à jour par Christophe Siraut il y a 26 jours

Le raisonnement et le patch me semblent corrects. Est-ce que tu attends une forte amélioration? Je me dis que la boucle que tu propose implique une requête sur chaque schéma, opération qui serait peut-être aussi coûteuse que d'appeler run_migrations() sur le schéma?

#7 Mis à jour par Frédéric Péters il y a 26 jours

Est-ce que tu attends une forte amélioration ?

C'est massif sur le cas plutôt commun de zéro migration et nombreux tenants.

#8 Mis à jour par Christophe Siraut il y a 26 jours

  • Statut changé de Solution proposée à Solution validée

#9 Mis à jour par Frédéric Péters il y a 26 jours

  • Statut changé de Solution validée à Résolu (à déployer)
commit 37f7dff960bc0ed228c3891ca32daf05e790a474
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Jan 7 14:09:24 2019 +0100

    multitenant: skip tenants where all migrations are applied (#29522)

#10 Mis à jour par Frédéric Péters il y a 26 jours

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF