Migration vers Django 2.2 depuis la version 1.11 -- les anciennes migrations sans on_delete dans ForeignKey cassent tout

Question

Je travaille à la mise à jour de mon ancienne application de Django 1.11.13 à 2.2.8. J'ai consciencieusement réglé tous les problèmes de compatibilité, mais il y en a un que je n'arrive pas à résoudre. Lorsque j'essaie de démarrer le serveur web dans mon environnement local, j'obtiens cette erreur (qui ne montre que la fin de la trace d'erreur complète qui apparaît) :

  File "/Users/me/my_app/my_model/migrations/0001_initial.py", line 37, in Migration
    ('entry', models.ForeignKey(to='my_model.Entry')),
TypeError: __init__() missing 1 required positional argument: 'on_delete'

Je comprends pourquoi on_delete est maintenant nécessaire -- je viens de passer un certain temps à mettre à jour mes modèles partout pour tenir compte de ce changement -- mais je n'ai aucune idée de la façon de résoudre ce problème particulier sans passer par des douzaines d'anciens fichiers de migration pour les rendre conformes ?!

• J'ai essayé squashmigrations pour au moins réduire le nombre d'endroits à nettoyer, mais j'ai obtenu exactement le même résultat. TypeError .

• J'ai essayé d'utiliser l'ancienne version de Django pour squashmigrations . J'ai réussi à éviter la TypeError mais s'est retrouvée avec un énorme désordre d'erreurs d'importation circulaires.

• Comme je n'ai pas besoin de l'historique de la migration pour revenir en arrière, j'ai essayé de suivre la procédure suivante ces instructions (scénario 2) pour effacer l'historique de la migration tout en conservant la base de données existante. mais je ne pouvais pas courir makemigrations pour rattraper les changements que j'ai faits pour rendre mes modèles compatibles avec Django 2.2, et quand j'ai décidé de passer outre et de m'en occuper plus tard, showmigrations a échoué avec la même TypeError . (Existe-t-il un autre moyen d'obtenir un nouvel ensemble de migrations initiales basées sur la base de données actuelle ? Cela ne peut pas être basé sur les modèles puisque les modèles ont des changements liés à la mise à jour qui ne sont pas encore reflétés dans la base de données).

• J'ai déplacé les migrations vers un emplacement non standard, ce qui a permis au serveur de démarrer, mais il est désormais impossible de faire quoi que ce soit en rapport avec la migration, et bien sûr, une fois que j'ai déménagé, tout se casse à nouveau la figure...

J'ai envisagé de supprimer toute ma base de données et tout l'historique des migrations, de reconstruire les tables à partir de zéro avec un nouvel ensemble de migrations initiales, puis de réinitialiser les données à partir d'une sauvegarde, mais il y a quelques tables énormes qui feraient que cela prendrait un certain temps... et cela semble plutôt être l'approche nucléaire. Suis-je obligé de modifier un grand nombre de très vieilles migrations pour qu'elles soient conformes à Django 2.2 sans raison réelle puisque je ne vais jamais faire remonter mon projet aussi loin ? Comment cela peut-il être juste ?

Answer 1

En tant que Iain Shelvington dans un commentaire sous la question,

Supprimez d'abord tous vos fichiers et dossiers de migration, puis exécutez makemigrations avec le "on_delete" - cela devrait créer quelques fichiers de migration "initiaux". Ensuite, vous devrez vous connecter à votre base de données et supprimer toutes les entrées de vos applications, puis vous devrez exécuter les commandes suivantes manage.py migrate --fake - cela permettra d'entrer dans la base de données les entrées pour les migrations nouvellement créées, mais ne les appliquera pas.