Quelle est la procédure pour désinstaller complètement une application Django, avec suppression de la base de données?
db.sqlite3
, et retirez- INSTALLED_APPS
en settings.py
?
Quelle est la procédure pour désinstaller complètement une application Django, avec suppression de la base de données?
db.sqlite3
, et retirez- INSTALLED_APPS
en settings.py
?
Réponses:
Django <1.7 a une commande de gestion pratique qui vous donnera le SQL nécessaire pour supprimer toutes les tables d'une application. Consultez la documentation sqlclear pour plus d'informations. Fondamentalement, l'exécution ./manage.py sqlclear my_app_name
vous permet d'obtenir les instructions SQL qui doivent être exécutées pour éliminer toutes les traces de l'application dans votre base de données. Vous devez toujours copier et coller (ou diriger) ces instructions dans votre client SQL. Pour Django 1.7 et plus, utilisez ./manage.py migrate my_app_name zero
(voir la documentation de migrate ), qui exécute automatiquement le nettoyage de la base de données.
Pour supprimer l'application de votre projet, il vous suffit de la supprimer de celle de INSTALLED_APPS
votre projet settings.py
. Django ne chargera plus l'application.
Si vous ne voulez plus que les fichiers de l'application traînent, supprimez le répertoire de l'application de votre répertoire de projet ou d'un autre emplacement sur votre PYTHONPATH où il réside.
(facultatif) Si l'application stockait des fichiers multimédias, des fichiers de cache ou d'autres fichiers temporaires quelque part, vous souhaiterez peut-être les supprimer également. Méfiez-vous également des données de session persistantes qui pourraient être restées de l'application.
(facultatif) Je supprimerais également tous les types de contenu périmés.
Ainsi.
from django.contrib.contenttypes.models import ContentType
for c in ContentType.objects.all():
if not c.model_class():
print "deleting %s"%c # print(f"deleting {c}") # for Python 3.6+
c.delete()
./manage.py migrate my_app_name zero
. Et il exécutera également automatiquement le SQL.
sqlclear
a été supprimé dans Django 1.9 donc cette réponse n'est valable que pour les versions précédentes. Voir: docs.djangoproject.com/en/1.10/releases/1.9/…
include("appname.urls")
du projeturls.py
settings.py
dans INSTALLED_APPS
la ligne de l'application inutile__pycache__
et migrate
à votre projet models.py
views.py
, admin.py
fin, etc. urls.py
vos applications inutilespython manage.py migrate
etpython manage.py syncdb
L'application django est un «ensemble» de fichiers * .py et un répertoire avec un nom d'application-django. Ainsi, vous pouvez simplement supprimer tout le dossier avec tous les fichiers * .py
Pour "supprimer" des tables de la base de données, vous devez utiliser DELETE FROM <app-name_table-names>
De plus, vous devez supprimer les lignes avec le nom de l'application de setting.py dans un répertoire racine
Dans mon contexte les projets existent plusieurs fois: j'ai un système de développement, certains coéquipiers ont un système de développement, il y a un système de mise en scène pour le client et un système de production. Cela signifie que je ne veux pas exécuter de commandes sql à la main. Je veux que ce soit automatisé.
Objectif: supprimer l'application et toutes les tables de la base de données.
supprimer tous les fichiers de l'application, sauf le dossier "migrations"
Exécutez cette commande: manage.py makemigrations -n drop_all_tables my_app_to_remove
Le répertoire ressemble maintenant à ceci:
my_app_to_remove/
my_app_to_remove/__init__.py
my_app_to_remove/migrations
my_app_to_remove/migrations/0001_initial.py
my_app_to_remove/migrations/....
my_app_to_remove/migrations/0030_drop_all_tables.py
my_app_to_remove/migrations/__init__.py
Laissez my_app_to_remove
dans le fichier "settings.py".
Mettez à jour tous les projets. Dites aux coéquipiers de mettre à jour leur projet et d'exécuter les migrations.
Supprimez maintenant "my_app_to_remove" de settings.py et déployez à nouveau.
J'aime vraiment les étapes de cet article - il inclut le support de migration .
Peut-être qu'il doit être adapté dans deux mises à jour de code - mais semble vraiment sécurisé lorsque vous devez travailler avec de nombreux déploiements (comme: phase de test, version BETA et production - dans mon cas)