Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026
Cron / Management Command

Migration Analyze (V2) — Analyzer “Models / Migrations / DB” + prescriptions

Objectif : arrêter la “pêche aux infos” en cas de migrations Django infernales. Ce cron croise : Data Model Django + plan de migrations + schéma réel SQL (MySQL/MariaDB, PostgreSQL, SQLite), puis sort : risques, diagnostic, et surtout des actions recommandées.

MariaDB / MySQL PostgreSQL SQLite 1061 duplicate key 1071 key too long Recommendations Auto-fix (1061) JSON export
  1. Plan : liste des opérations de migrations (forward) pour avoir la trajectoire.
  2. Risks : détecte les erreurs probables (1061 / 1071, index TEXT/BLOB, colonnes manquantes).
  3. Recommendations : propose “quoi faire” (FAKE migration vs DROP index, etc.).
  4. Auto-fix (optionnel) : peut DROP les index en conflit (mode dev/staging).
  5. Export JSON : idéal pour un dashboard IDEO-Lab (findings + actions + fixes appliqués).
Résultats typiques :
  • MYSQL_1061_RISK → index existe déjà : FAKE si identique, sinon DROP.
  • MYSQL_1071_RISK → clé trop longue : propose max_length=191, réduire composite, ou prefix index via RunSQL.
  • MYSQL_INDEX_SIZE_UNKNOWN → table/colonne pas encore migrée (INFO) vs vrai risque TEXT/BLOB (WARN).

Étape 1 — Installation du Cron / Management Command

1) Où placer le fichier Python

Place la commande dans une app utilitaire (ex : toolbox, accounts, tools), ou directement dans l’app qui “porte” tes outils de maintenance.

Arborescence projet
your_project/
  toolbox/                           # ou accounts/, tools/...
    management/
      __init__.py
      commands/
        __init__.py
        migration_analyze.py          # <= le cron V2
Important : ne pas oublier les fichiers __init__.py dans management/ et commands/, sinon Django ne détectera pas la commande.

2) Copier le fichier migration_analyze.py (V2)

Tu peux copier-coller ta version V2 (celle qu’on vient de valider). :contentReference[oaicite:2]{index=2} Si tu veux proposer un download dans IDEO-Lab, place aussi une copie sous static/.

migration_analyze.py
Download .py
# (colle ici le contenu du fichier V2 — voir migration_analyze.py V2)
# Référence : :contentReference[oaicite:3]{index=3}

3) Vérifier que l’app est bien dans INSTALLED_APPS

settings.py
INSTALLED_APPS = [
  # ...
  "toolbox",   # ou l'app qui contient management/commands/migration_analyze.py
]

4) Test de présence de la commande

Terminal
python manage.py help | findstr migration_analyze
python manage.py migration_analyze --help
Si tu vois la commande dans --help, c’est OK : Django l’a détectée.

Étape 2 — Utilisation au quotidien

A) Diagnostic rapide (plan / diff / risks)

Plan migrations
# Affiche les opérations forward (résumé)
python manage.py migration_analyze --plan
Diff DB vs (heuristique)
# Détecte tables "orphelines" / manquantes (heuristique)
python manage.py migration_analyze --diff
Risk analysis (MariaDB/MySQL)
# Ton cas: MariaDB avec limite de clé = 1000
python manage.py migration_analyze --risks --mysql-max-key-bytes 1000 --verbose

B) Cibler une app uniquement

Focus app(s)
# Exemple : on ne regarde que l’app "weglot"
python manage.py migration_analyze --risks --apps weglot --mysql-max-key-bytes 1000

C) Export JSON (pour dashboard IDEO-Lab)

Export JSON
python manage.py migration_analyze --risks --mysql-max-key-bytes 1000 --export-json migration_report.json
Le JSON contient : findings, recommendations et fixes_applied. C’est parfait pour ton pattern “Analyzer IDEO-Lab” (cards + détails + actions).

Étape 3 — Auto-Fix & Sécurité

⚠️ Mode destructif (DROP index) :
  • Autorisé : dev / staging / environnements de test.
  • Déconseillé : production (sauf procédure contrôlée + backup + maintenance window).

A) Auto-fix des 1061 (dry-run d’abord)

Auto-fix 1061 (dry-run)
# Affiche le DROP proposé, sans exécuter
python manage.py migration_analyze --risks --fix-1061 drop --dry-run --emit-sql

B) Auto-fix des 1061 (exécution)

Auto-fix 1061 (apply)
# Applique DROP INDEX automatiquement, puis tu relances migrate
python manage.py migration_analyze --risks --fix-1061 drop --emit-sql
python manage.py migrate

C) Mode “safe” : suggestion de FAKE

Si l’index DB est déjà identique à l’index prévu, la V2 te propose plutôt : faker la migration (aligner l’historique) plutôt que drop/recreate.

Auto-fix 1061 (safe suggestions)
# N'applique rien: affiche une commande "migrate ... --fake" suggérée
python manage.py migration_analyze --risks --fix-1061 fake
Bonne pratique : en prod, privilégie la stratégie FAKE quand l’index existe déjà et qu’il est strictement identique, sinon maintenance contrôlée.

FAQ / Dépannage

1) “Model was already registered / Reloading models is not advised”

Ça arrive souvent quand un environnement reload (shell, autoreload, import double, etc.). Ce warning n’empêche pas forcément l’analyse, mais si tu le vois systématiquement :
  • évite de lancer la commande dans un contexte “reload” (runserver autoreload, certains IDE)
  • lance depuis un terminal propre
  • vérifie les imports (pas de double import de module)

2) “MYSQL_INDEX_SIZE_UNKNOWN”

  • INFO (TABLE/COLUMN missing) : normal si la table n’est pas encore migrée.
  • WARN (TEXT/BLOB) : risque réel → re-design (CharField) ou prefix index via RunSQL.

3) “MYSQL_1071_RISK key too long” (MariaDB)

Causes classiques :
  • CharField trop long dans un index composite (utf8mb4 ≈ 4 bytes/char).
  • index sur plusieurs champs varchar(255).
Fix typique :
  • réduire max_length des champs indexés à 191
  • réduire le nombre de colonnes dans l’index composite

4) “Je veux l’intégrer dans un pipeline / cron”

Voir la modal “Intégration Cron”.