Development #29522
accélération migrate_schemas
0%
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)
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Frédéric Péters il y a plus de 5 ans
- 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).
Mis à jour par Thomas Noël il y a plus de 5 ans
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é".
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
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 (?)).
Mis à jour par Frédéric Péters il y a environ 5 ans
- Fichier 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch 0001-multitenant-skip-tenants-where-all-migrations-are-ap.patch ajouté
Modification pour ne pas toucher au comportement quand --fake est passé.
Mis à jour par Christophe Siraut il y a environ 5 ans
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?
Mis à jour par Frédéric Péters il y a environ 5 ans
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.
Mis à jour par Christophe Siraut il y a environ 5 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a environ 5 ans
- 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)
Mis à jour par Frédéric Péters il y a environ 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
multitenant: skip tenants where all migrations are applied (#29522)