django-admin - En ligne dans le Cloud

PROGRAMME:

Nom

django-admin - Script utilitaire pour le framework Web Django

Django-admin est l'utilitaire de ligne de commande de Django pour les tâches administratives. Ce document
décrit tout ce qu'il peut faire.

Avant Django 1.7, Django-admin n'a été installé que comme django-admin.py.

Par ailleurs, gérer.py est automatiquement créé dans chaque projet Django. gérer.py est une
enveloppe mince autour Django-admin qui s'occupe de plusieurs choses pour vous avant
déléguer à Django-admin:

· Il met le package de votre projet sur chemin système.

· Il définit le DJANGO_SETTINGS_MODULE variable d'environnement afin qu'elle pointe vers votre
projets settings.py fichier.

· Il appelle django.setup() pour initialiser divers internes de Django.

django.setup() n'existait pas dans les versions précédentes de Django.

Le Django-admin le script devrait être sur votre chemin système si vous avez installé Django via son
configuration.py utilitaire. Si ce n'est pas sur votre chemin, vous pouvez le trouver dans site-paquets/django/bin
dans votre installation Python. Envisagez de créer un lien symbolique à partir d'un endroit sur votre chemin, tel
as / usr / local / bin.

Pour les utilisateurs de Windows, qui n'ont pas de fonctionnalité de lien symbolique disponible, vous pouvez copier
django-admin.exe vers un emplacement sur votre chemin existant ou modifiez le PATH paramètres (sous
Paramètres - Contrôle Webinars - Système - Avancé - Environnement...) pour pointer vers son installé
emplacement.

Généralement, lorsque vous travaillez sur un seul projet Django, il est plus facile d'utiliser gérer.py que
Django-admin. Si vous devez basculer entre plusieurs fichiers de paramètres Django, utilisez
Django-admin avec DJANGO_SETTINGS_MODULE ou l' --Les paramètres commande option de ligne.

Les exemples de ligne de commande tout au long de ce document utilisent Django-admin être cohérent, mais
n'importe quel exemple peut utiliser gérer.py tout aussi bien.

UTILISATION

$ django-admin [options]
$ gérer.py [options]

commander devrait être l'une des commandes répertoriées dans ce document. Options, lequel est
facultatif, doit être égal à zéro ou plusieurs des options disponibles pour la commande donnée.

Obtenir d'exécution vous aider
Django-admin vous aider

Courir Django-admin vous aider pour afficher des informations d'utilisation et une liste des commandes fournies par
chaque application.

Courir Django-admin vous aider --commandes pour afficher une liste de toutes les commandes disponibles.

Courir Django-admin vous aider pour afficher une description de la commande donnée et une liste
de ses options disponibles.

 Application noms
De nombreuses commandes prennent une liste de « noms d'applications ». Un "nom d'application" est le nom de base du package
contenant vos modèles. Par exemple, si votre INSTALLED_APPS contient la chaîne
'monsite.blog', le nom de l'application est blog.

Détermination le version
Django-admin version

Courir Django-admin version pour afficher la version actuelle de Django.

La sortie suit le schéma décrit dans PEP 386:

1.4.dev17026
1.4a1
1.4

visualisation déboguer sortie
Utilisez --verbosité pour spécifier la quantité d'informations de notification et de débogage qui
Django-admin devrait s'imprimer sur la console. Pour plus de détails, consultez la documentation du
--verbosité option.

DISPONIBLE COMMANDES

choisissez <nom de l'application nom de l'application ...>
Django-admin choisissez

Utilise le Système choisissez cadre pour inspecter l'ensemble du projet Django à la recherche de problèmes courants.

Le cadre de vérification du système confirmera qu'il n'y a aucun problème avec votre installation
modèles ou vos inscriptions administrateur. Il fournira également des avertissements de compatibilité commune
problèmes introduits par la mise à niveau de Django vers une nouvelle version. Des contrôles personnalisés peuvent être introduits
par d'autres bibliothèques et applications.

Par défaut, toutes les applications seront vérifiées. Vous pouvez vérifier un sous-ensemble d'applications en fournissant une liste
des étiquettes d'applications en tant qu'arguments :

python manage.py vérifier auth admin myapp

Si vous ne spécifiez aucune application, toutes les applications seront vérifiées.

--étiqueter

Le Système choisissez cadre effectue de nombreux types de vérifications. Ces types de chèques sont
classés avec des balises. Vous pouvez utiliser ces balises pour restreindre les contrôles effectués à
ceux d'une catégorie particulière. Par exemple, pour effectuer uniquement la sécurité et la compatibilité
contrôles, vous exécuteriez :

python manage.py check --tag security --tag compatibilité

--list-tags

Répertoriez toutes les balises disponibles.

--déployer

Le --déployer L'option active des vérifications supplémentaires qui ne sont pertinentes que dans un
paramètre de déploiement.

Vous pouvez utiliser cette option dans votre environnement de développement local, mais comme votre
le module des paramètres de développement peut ne pas avoir beaucoup de vos paramètres de production, vous
voulez probablement pointer le choisissez commande à un module de paramètres différent, soit en définissant
le DJANGO_SETTINGS_MODULE variable d'environnement, ou en passant la --Les paramètres option:

python manage.py check --deploy --settings=production_settings

Ou vous pouvez l'exécuter directement sur un déploiement de production ou intermédiaire pour vérifier que le
les paramètres corrects sont utilisés (en omettant --Les paramètres). Vous pourriez même en faire une partie de votre
suite de tests d'intégration.

compiler des messages
Django-admin compiler des messages

Compile les fichiers .po créés par faire des messages aux fichiers .mo à utiliser avec le gettext intégré
Support. Voir /sujets/i18n/index.

Utilisez l'option --lieu option (ou sa version plus courte -l) pour spécifier les paramètres régionaux à traiter.
S'il n'est pas fourni, tous les paramètres régionaux sont traités.

Utilisez l'option --exclure option (ou sa version plus courte -x) pour spécifier les paramètres régionaux à exclure
du traitement. S'il n'est pas fourni, aucun paramètre régional n'est exclu.

Tu peux passer --use-fuzzy option (ou -f) pour inclure des traductions floues dans les fichiers compilés.

Ajouté --exclure et --use-fuzzy options.

Exemple d'utilisation:

messages de compilation django-admin --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
messages de compilation django-admin --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

créer un cache
Django-admin créer un cache

Crée les tables de cache à utiliser avec le moteur de cache de la base de données. Voir /sujets/cache pour
pour en savoir davantage.

Le --base de données L'option peut être utilisée pour spécifier la base de données sur laquelle la table de cache sera
être installé.

Il n'est plus nécessaire de fournir le nom de la table de cache ou le --base de données option. Django
prend ces informations de votre fichier de paramètres. Si vous avez configuré plusieurs caches ou
plusieurs bases de données, toutes les tables de cache sont créées.

dbshell
Django-admin dbshell

Exécute le client de ligne de commande pour le moteur de base de données spécifié dans votre ENGINE réglage,
avec les paramètres de connexion spécifiés dans votre UTILISATEUR, MOT DE PASSE, etc., paramètres.

· Pour PostgreSQL, cela exécute le psql client en ligne de commande.

· Pour MySQL, cela exécute le mysql client en ligne de commande.

· Pour SQLite, cela exécute le sqlite3 client en ligne de commande.

Cette commande suppose que les programmes sont sur votre PATH pour qu'un simple appel au programme
Nom (psql, mysql, sqlite3) trouvera le programme au bon endroit. Il n'y a aucun moyen de
spécifier l'emplacement du programme manuellement.

Le --base de données L'option peut être utilisée pour spécifier la base de données sur laquelle ouvrir un shell.

paramètres de différence
Django-admin paramètres de différence

Affiche les différences entre le fichier de paramètres actuel et les paramètres par défaut de Django.

Les paramètres qui n'apparaissent pas dans les valeurs par défaut sont suivis de "###". Par exemple, la valeur par défaut
les paramètres ne définissent pas ROOT_URLCONF, De sorte ROOT_URLCONF est suivi par "###" à la sortie de
paramètres de différence.

Le --tout une option peut être fournie pour afficher tous les paramètres, même s'ils ont ceux de Django
valeur par défaut. Ces paramètres sont précédés de "###".

vidage de données <étiquette_app étiquette_app app_label.Modèle ...>
Django-admin vidage de données

Les sorties vers la sortie standard toutes les données de la base de données associées au nom
applications).

Si aucun nom d'application n'est fourni, toutes les applications installées seront vidés.

La sortie de vidage de données peut être utilisé comme entrée pour charger les données.

Notez que vidage de données utilise le gestionnaire par défaut sur le modèle pour sélectionner les enregistrements à
décharger. Si vous utilisez un Customiser manager comme gestionnaire par défaut et il filtre certains des
enregistrements disponibles, tous les objets ne seront pas vidés.

Le --tout une option peut être fournie pour spécifier que vidage de données devrait utiliser la base de Django
gestionnaire, vidant les enregistrements qui pourraient autrement être filtrés ou modifiés par un
gestionnaire.

--format

Par défaut, vidage de données formatera sa sortie en JSON, mais vous pouvez utiliser le --format option
pour spécifier un autre format. Les formats actuellement pris en charge sont répertoriés dans
formats de sérialisation.

--indentation

Par défaut, vidage de données affichera toutes les données sur une seule ligne. Ce n'est pas facile pour les humains de
lire, afin que vous puissiez utiliser le --indentation option pour joliment imprimer la sortie avec un certain nombre de
espaces d'indentation.

Le --exclure une option peut être fournie pour empêcher des applications ou des modèles spécifiques (spécifiés
comme sous la forme de app_label.ModelName) d'être vidé. Si vous spécifiez un nom de modèle à
vidage de données, la sortie sous-évaluée sera limitée à ce modèle, plutôt qu'à l'ensemble
application. Vous pouvez également mélanger des noms d'application et des noms de modèle.

Le --base de données L'option peut être utilisée pour spécifier la base de données à partir de laquelle les données seront vidées.

--naturel-étranger

Lorsque cette option est spécifiée, Django utilisera le clé_naturelle() méthode de modèle pour sérialiser
toute clé étrangère et relation plusieurs-à-plusieurs avec des objets du type qui définit le
méthode. Si vous jetez contrib.auth Autorisation objets ou contrib.contenttypes
ContentType objets, vous devriez probablement utiliser ce drapeau. Voir le sciences naturelles clés
documentation pour plus de détails sur cette option et la suivante.

--naturel-primaire

Lorsque cette option est spécifiée, Django ne fournira pas la clé primaire dans le sérialisé
données de cet objet puisqu'il peut être calculé lors de la désérialisation.

--Naturel

Obsolète depuis la version 1.7 : équivalent au --naturel-étranger option; Utiliser ça
à la place.

Utilisez sciences naturelles clés pour représenter n'importe quelle clé étrangère et relation plusieurs-à-plusieurs avec un modèle
qui fournit une définition de clé naturelle.

--pks

Par défaut, vidage de données affichera tous les enregistrements du modèle, mais vous pouvez utiliser le --pks
option pour spécifier une liste de clés primaires séparées par des virgules sur lesquelles filtrer. C'est seulement
disponible lors du dumping d'un modèle.

--output

Par défaut vidage de données affichera toutes les données sérialisées sur la sortie standard. Cette option
permet de spécifier le fichier dans lequel les données doivent être écrites.

affleurer
Django-admin affleurer

Supprime toutes les données de la base de données, réexécute tous les gestionnaires de post-synchronisation et
réinstalle tous les appareils de données initiaux.

Le --pas d'entrée Une option peut être fournie pour supprimer toutes les invites de l'utilisateur.

Le --base de données L'option peut être utilisée pour spécifier la base de données à vider.

--pas de données initiales
Utilisez --pas de données initiales pour éviter de charger l'appareil initial_data.

inspectedb
Django-admin inspectedb

Introspecte les tables de base de données et les vues dans la base de données pointée par le Nom mise
et génère un module de modèle Django (un modèles.py fichier) vers la sortie standard.

Utilisez ceci si vous avez une base de données héritée avec laquelle vous souhaitez utiliser Django. Le script
inspectera la base de données et créera un modèle pour chaque table ou vue qu'elle contient.

Comme vous pouvez vous y attendre, les modèles créés auront un attribut pour chaque champ dans le
table ou vue. Noter que inspectedb a quelques cas particuliers dans sa sortie de nom de champ :

· Si inspectedb ne peut pas mapper le type d'une colonne à un type de champ de modèle, il utilisera Champ de texte et
va insérer le commentaire Python 'Cette champ type is a deviner.' à côté du terrain dans le
modèle généré.

· Si le nom de la colonne de la base de données est un mot réservé Python (tel que 'passe', 'classer' or
'pour'), inspectedb va ajouter '_champ' au nom de l'attribut. Par exemple, si un tableau
a une colonne 'pour', le modèle généré aura un champ 'for_field', Avec le
db_colonne attribut défini sur 'pour'. inspectedb va insérer le commentaire Python 'Champ
renommé car it était a Python réservé mot.' à côté du terrain.

Cette fonctionnalité est conçue comme un raccourci, et non comme une génération de modèle définitive. Après l'avoir exécuté,
vous voudrez examiner vous-même les modèles générés pour effectuer des personnalisations. Dans
En particulier, vous devrez réorganiser l'ordre des modèles, de sorte que les modèles faisant référence à d'autres
les modèles sont commandés correctement.

Les clés primaires sont automatiquement introspectées pour PostgreSQL, MySQL et SQLite, dans lesquelles
cas Django met dans le primary_key=Vrai au besoin.

inspectedb fonctionne avec PostgreSQL, MySQL et SQLite. La détection de clé étrangère ne fonctionne que dans
PostgreSQL et avec certains types de tables MySQL.

Django ne crée pas de valeurs par défaut de base de données lorsqu'un défaut est spécifié sur un champ de modèle.
De même, les valeurs par défaut de la base de données ne sont pas traduites en valeurs par défaut des champs de modèle ni détectées dans aucun
mode par inspectedb.

Par défaut, inspectedb crée des modèles non gérés. C'est-à-dire, gérés = Faux dans le modèle
Meta La classe dit à Django de ne pas gérer la création, la modification et la suppression de chaque table.
Si vous souhaitez autoriser Django à gérer le cycle de vie de la table, vous devrez modifier le
gérés Option de Vrai (ou simplement l'enlever car Vrai est sa valeur par défaut).

Le --base de données L'option peut être utilisée pour spécifier la base de données à introspecter.

Une fonctionnalité pour inspecter les vues de la base de données a été ajoutée. Dans les versions précédentes, seuls les tableaux (pas
vues) ont été inspectés.

charger les données <luminaire luminaire ...>
Django-admin charger les données

Recherche et charge le contenu de l'appareil nommé dans la base de données.

Le --base de données L'option peut être utilisée pour spécifier la base de données sur laquelle les données seront
chargé.

--ignoreinexistant

Le --ignoreinexistant peut être utilisée pour ignorer les champs et les modèles qui peuvent avoir été
supprimé depuis que l'appareil a été généré à l'origine.

--application

Le --application L'option peut être utilisée pour spécifier une seule application dans laquelle rechercher des appareils plutôt que
en parcourant toutes les applications.

--application était ajouté.

--ignoreinexistant ignore également les modèles inexistants.

Ce qui est a luminaire ?
A luminaire est une collection de fichiers qui contiennent le contenu sérialisé de la base de données.
Chaque appareil a un nom unique, et les fichiers qui composent l'appareil peuvent être distribués
sur plusieurs répertoires, dans plusieurs applications.

Django recherchera les appareils à trois endroits :

1. dans le agencements répertoire de chaque application installée

2. Dans n'importe quel répertoire nommé dans le FIXTURE_DIRS mise

3. Dans le chemin littéral nommé par le projecteur

Django chargera tous les appareils qu'il trouvera dans ces emplacements qui correspondent à ceux fournis.
noms des appareils.

Si le projecteur nommé a une extension de fichier, seuls les projecteurs de ce type seront chargés. Pour
Exemple:

django-admin loaddata mydata.json

ne chargerait que les appareils JSON appelés mes données. L'extension du luminaire doit correspondre au
nom enregistré d'un sérialiseur (par exemple, json or xml).

Si vous omettez les extensions, Django recherchera tous les types d'appareils disponibles pour une correspondance
fixation. Par exemple:

django-admin loaddata mes données

rechercherait n'importe quel appareil de n'importe quel type d'appareil appelé mes données. Si un répertoire d'appareils
contenu mesdonnées.json, cet appareil serait chargé en tant qu'appareil JSON.

Les appareils nommés peuvent inclure des composants de répertoire. Ces répertoires seront
inclus dans le chemin de recherche. Par exemple:

django-admin loaddata foo/bar/mesdonnées.json

chercherait /fixtures/foo/bar/mydata.json pour chaque application installée,
/foo/bar/mydata.json pour chaque répertoire dans FIXTURE_DIRS, et le chemin littéral
foo/bar/mesdonnées.json.

Lorsque les fichiers de luminaires sont traités, les données sont enregistrées dans la base de données telles quelles. Modèle défini
sauvegarder() les méthodes ne sont pas appelées et aucune pré_sauvegarder or post_sauvegarder les signaux seront appelés avec
brut = vrai puisque l'instance ne contient que des attributs locaux au modèle. Tu peux,
par exemple, souhaitez désactiver les gestionnaires qui accèdent aux champs connexes qui ne sont pas présents
pendant le chargement du projecteur et lèverait autrement une exception :

de django.db.models.signals importer post_save
à partir de .models importer MyModel

def mon_handler(**kwargs):
# désactiver le gestionnaire pendant le chargement du projecteur
si kwargs['brut'] :
retourner
...

post_save.connect(my_handler, sender=MyModel)

Vous pouvez également écrire un simple décorateur pour encapsuler cette logique :

à partir de functools importer des enveloppes

def Disable_for_loaddata (signal_handler) :
"" "
Décorateur qui désactive les gestionnaires de signaux lors du chargement des données de luminaire.
"" "
@wraps(signal_handler)
def wrapper(*args, **kwargs):
si kwargs['brut'] :
retourner
signal_handler(*args, **kwargs)
emballage de retour

@disable_for_loaddata
def mon_handler(**kwargs):
...

Sachez simplement que cette logique désactivera les signaux chaque fois que les appareils sont désérialisés,
pas seulement pendant charger les données.

Notez que l'ordre dans lequel les fichiers d'appareils sont traités n'est pas défini. Cependant, tout
les données de l'appareil sont installées en une seule transaction, de sorte que les données d'un appareil peuvent faire référence
données dans un autre appareil. Si le backend de la base de données prend en charge les contraintes au niveau des lignes, ces
les contraintes seront vérifiées à la fin de la transaction.

Le vidage de données La commande peut être utilisée pour générer une entrée pour charger les données.

Comprimé agencements
Les luminaires peuvent être compressés dans Zip *: français, gz, ou bz2 format. Par exemple:

django-admin loaddata mydata.json

chercherait l'un des mesdonnées.json, mesdonnées.json.zip, mesdonnées.json.gz, ou mesdonnées.json.bz2.
Le premier fichier contenu dans une archive compressée zip est utilisé.

Notez que si deux appareils avec le même nom mais un type d'appareil différent sont découverts
(par exemple, si mesdonnées.json et mesdonnées.xml.gz ont été trouvés dans le même répertoire d'appareils),
l'installation de l'appareil sera abandonnée et toutes les données installées dans l'appel à charger les données seront
être supprimé de la base de données.

MySQL avec MyISAM et les appareils

Le moteur de stockage MyISAM de MySQL ne supporte pas les transactions ou les contraintes,
donc si vous utilisez MyISAM, vous n'obtiendrez pas de validation des données de luminaire, ou une annulation si
plusieurs fichiers de transaction sont trouvés.

Spécifique à la base de données agencements
Si vous êtes dans une configuration à plusieurs bases de données, vous avez peut-être des données d'appareil que vous souhaitez charger
sur une base de données, mais pas sur une autre. Dans cette situation, vous pouvez ajouter une base de données
identifiant dans les noms de vos appareils.

Par exemple, si votre BASES DE DONNÉES le paramètre a une base de données 'master' définie, nommez l'appareil
mesdonnées.master.json or mesdonnées.master.json.gz et l'appareil ne sera chargé que lorsque vous
spécifiez que vous voulez charger des données dans le maître base de données.

faire des messages
Django-admin faire des messages

Parcourt toute l'arborescence des sources du répertoire actuel et extrait toutes les chaînes marquées
Pour la traduction. Il crée (ou met à jour) un fichier de message dans le conf/locale (dans le Django
tree) ou le répertoire des paramètres régionaux (pour le projet et l'application). Après avoir apporté des modifications au
messages avec lesquels vous devez les compiler compiler des messages à utiliser avec le module intégré
prise en charge de gettext. Voir le i18n Documentation pour en savoir plus.

--tout

Utilisez l'option --tout or -a option pour mettre à jour les fichiers de messages pour toutes les langues disponibles.

Exemple d'utilisation:

django-admin makemessages --all

--extension

Utilisez l'option --extension or -e option pour spécifier une liste d'extensions de fichiers à examiner (par défaut :
".html", ".txt").

Exemple d'utilisation:

django-admin makemessages --locale=de --extension xhtml

Séparez plusieurs extensions par des virgules ou utilisez -e ou --extension plusieurs fois :

django-admin makemessages --locale=de --extension=html,txt --extension xml

Utilisez l'option --lieu option (ou sa version plus courte -l) pour spécifier les paramètres régionaux à traiter.

Utilisez l'option --exclure option (ou sa version plus courte -x) pour spécifier les paramètres régionaux à exclure
du traitement. S'il n'est pas fourni, aucun paramètre régional n'est exclu.

Exemple d'utilisation:

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

Ajouté le --précédent option à la msgmerge lors de la fusion avec des fichiers po existants.

--domaine

Utilisez l'option --domaine or -d option pour changer le domaine des fichiers de messages. Actuellement
prise en charge:

· Django pour tous *.py, *.html et *.SMS fichiers (par défaut)

· djangojs pour *.js fichiers

--liens symboliques

Utilisez l'option --liens symboliques or -s option pour suivre les liens symboliques vers les répertoires lors de la recherche de nouveaux
chaînes de traduction.

Exemple d'utilisation:

django-admin makemessages --locale=de --symlinks

--ignorer

Utilisez l'option --ignorer or -i option pour ignorer les fichiers ou répertoires correspondant au donné globDe style
modèle. Utilisez plusieurs fois pour en ignorer davantage.

Ces modèles sont utilisés par défaut : 'CVS', '.*', '*~', '*.pyc'

Exemple d'utilisation:

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore

Utilisez l'option --no-default-ignore option pour désactiver les valeurs par défaut de --ignorer.

--sans emballage

Utilisez l'option --sans emballage option pour désactiver la rupture des longues lignes de message en plusieurs lignes dans
fichiers de langue.

--pas d'emplacement

Utilisez l'option --pas d'emplacement option pour ne pas écrire '#: nom de fichier:ligne' lignes de commentaire dans la langue
des dossiers. Notez que l'utilisation de cette option rend plus difficile pour les traducteurs techniquement qualifiés de
comprendre le contexte de chaque message.

--garder-pot

Utilisez l'option --garder-pot option pour empêcher Django de supprimer les erreurs de débogage temporaires
ce qui peut empêcher la création des fichiers de langue finaux.

VOIR AUSSI:
See personnalisation-faire des messages pour obtenir des instructions sur la façon de personnaliser les mots-clés qui
faire des messages passe à xgettext.

faire des migrations [ ]
Django-admin faire des migrations

Crée de nouvelles migrations en fonction des modifications détectées sur vos modèles. Les migrations, leur
relation avec les applications et plus sont couverts en profondeur dans le migrations Documentation.

Fournir un ou plusieurs noms d'application comme arguments limitera les migrations créées vers le
application(s) spécifiée(s) et toutes les dépendances nécessaires (le tableau à l'autre extrémité d'un Clé étrangère,
par exemple).

--vide

Le --vide l'option entraînera faire des migrations pour générer une migration vide pour le
applications spécifiées, pour l'édition manuelle. Cette option est réservée aux utilisateurs avancés et ne doit pas
être utilisé à moins que vous ne soyez familiarisé avec le format de migration, les opérations de migration et le
dépendances entre vos migrations.

- à sec

Le - à sec L'option montre quelles migrations seraient effectuées sans réellement écrire de
migrations des fichiers sur le disque. En utilisant cette option avec --verbosité 3 montrera également le
terminer les fichiers de migrations qui seraient écrits.

--fusionner

Le --fusionner L'option permet de résoudre les conflits de migration. Les --pas d'entrée l'option peut être
fourni pour supprimer les invites de l'utilisateur lors d'une fusion.

--Nom, -n

Le --Nom L'option vous permet de donner à la ou aux migrations un nom personnalisé au lieu d'un
une.

--sortir, -e

Le --sortir l'option entraînera faire des migrations pour quitter avec le code d'erreur 1 en l'absence de migration
sont créés (ou auraient été créés, s'ils étaient combinés avec - à sec).

émigrer [ [ ]]
Django-admin émigrer

Synchronise l'état de la base de données avec l'ensemble actuel de modèles et de migrations.
Les migrations, leur relation avec les applications et plus sont traitées en profondeur dans le migrations
Documentation.

Le comportement de cette commande change en fonction des arguments fournis :

· Aucun argument : toutes les applications migrées ont toutes leurs migrations exécutées, et toutes non migrées
les applications sont synchronisées avec la base de données,

· : l'application spécifiée a ses migrations exécutées, jusqu'à la migration la plus récente.
Cela peut également impliquer l'exécution de migrations d'autres applications, en raison de dépendances.

· : amène le schéma de la base de données à un état où le nom
la migration est appliquée, mais aucune migration ultérieure dans la même application n'est appliquée. Ceci peut
impliquer l'annulation de l'application des migrations si vous avez déjà migré au-delà de la migration nommée.
Utiliser le nom zéro pour annuler toutes les migrations d'une application.

Aimée base de données synchronisée, cette commande ne vous invite pas à créer un superutilisateur s'il n'en existe pas
(en supposant que vous utilisez django.contrib.auth). Utiliser créersuperutilisateur de le faire si vous le souhaitez.

Le --base de données L'option peut être utilisée pour spécifier la base de données à migrer.

--faux

Le --faux L'option indique à Django de marquer les migrations comme ayant été appliquées ou non appliquées,
mais sans réellement exécuter le SQL pour modifier votre schéma de base de données.

Ceci est destiné aux utilisateurs avancés pour manipuler directement l'état actuel de la migration si
ils appliquent manuellement les modifications ; sachez qu'en utilisant --faux court le risque de mettre
la table d'état de migration dans un état où la récupération manuelle sera nécessaire pour faire
les migrations s'exécutent correctement.

--faux-initial

Le --faux-initial L'option peut être utilisée pour permettre à Django d'ignorer la migration initiale d'une application
si toutes les tables de la base de données avec les noms de tous les modèles créés par tous Créer un modèle
dans cette migration existent déjà. Cette option est destinée à être utilisée lors de la première exécution
migrations contre une base de données qui préexistait à l'utilisation des migrations. Cette option ne fonctionne pas,
cependant, vérifiez le schéma de base de données correspondant au-delà des noms de table correspondants et n'est donc que
sûr à utiliser si vous êtes sûr que votre schéma existant correspond à ce qui est enregistré dans
votre migration initiale.

Obsolète depuis la version 1.8 : --liste l'option a été déplacée vers le afficher les migrations
commander.

runfcgi [choix]
Django-admin runfcgi

Obsolète depuis la version 1.7 : la prise en charge de FastCGI est obsolète et sera supprimée dans Django
1.9.

Démarre un ensemble de processus FastCGI utilisables avec n'importe quel serveur Web prenant en charge le
Protocole FastCGI. Voir le FastCGI déploiement Documentation pour les détails. Nécessite le
Module Python FastCGI de fluctuation.

En interne, cela encapsule l'objet d'application WSGI spécifié par le APPLICATION_WSGI
multiculturel.

Les options acceptées par cette commande sont passées à la bibliothèque FastCGI et n'utilisent pas le
'--' comme d'habitude pour les autres commandes de gestion Django.

protocole

protocole=PROTOCOLE

Protocole à utiliser. PROTOCOLE peuvent être fcgi, scgi, Ajp, etc. (la valeur par défaut est fcgi)

hôte

hôte=NOM D'HTE

Nom d'hôte sur lequel écouter.

port

port=NUMERO DE PORT

Port pour écouter.

douille

socket=FICHIER

Socket UNIX sur lequel écouter.

méthode

méthode=IMPL

Valeurs possibles: prefork or fileté (défaut prefork)

maxdemandes

maxrequêtes=NOMBRE

Nombre de requêtes traitées par un enfant avant qu'il ne soit tué et qu'un nouvel enfant soit fork (0 signifie
sans limites).

maxspare

maxspare=NOMBRE

Nombre maximum de processus / threads de rechange.

épargner

minspare=NOMBRE

Nombre minimum de processus / threads de rechange.

maxenfants

maxenfants=NOMBRE

Limite stricte du nombre de processus / threads.

démoniser

démoniser=BOOL

S'il faut se détacher du terminal.

fichier pid

pidfile=FICHIER

Écrire l'ID de processus généré dans le fichier DOSSIER.

répertoire de travail

workdir=RÉPERTOIRE

Changer de répertoire ANNUAIRE lors de la démonisation.

déboguer

débogage=BOOL

Définissez sur true pour activer les retraçages flup.

déconnexion

outlog=FICHIER

Écrire stdout sur le DOSSIER fichier.

journal des erreurs

errlog=FICHIER

Écrire stderr sur le DOSSIER fichier.

umask

umask=UMASK

Umask à utiliser lors de la démonisation. La valeur est interprétée comme un nombre octal (valeur par défaut
is 0o22).

Exemple d'utilisation:

django-admin runfcgi socket=/tmp/fcgi.sock méthode=prefork daemonize=true
pidfile=/var/run/django-fcgi.pid

Exécutez un serveur FastCGI en tant que démon et écrivez le PID généré dans un fichier.

serveur d'exécution [Port or adresse:port]
Django-admin serveur d'exécution

Démarre un serveur Web de développement léger sur la machine locale. Par défaut, le serveur
fonctionne sur le port 8000 sur l'adresse IP 127.0.0.1. Vous pouvez transmettre une adresse IP et un port
nombre explicitement.

Si vous exécutez ce script en tant qu'utilisateur avec des privilèges normaux (recommandé), vous n'aurez peut-être pas
accès pour démarrer un port sur un numéro de port faible. Les numéros de port faibles sont réservés au
superutilisateur (root).

Ce serveur utilise l'objet d'application WSGI spécifié par le APPLICATION_WSGI multiculturel.

N'UTILISEZ PAS CE SERVEUR DANS UN CADRE DE PRODUCTION. Il n'a pas fait l'objet d'audits de sécurité ou
des tests de performance. (Et c'est comme ça que ça va rester. Nous sommes en train de faire du Web
frameworks, pas des serveurs Web, donc améliorer ce serveur pour pouvoir gérer une production
l'environnement est en dehors de la portée de Django.)

Le serveur de développement recharge automatiquement le code Python pour chaque requête, selon les besoins. Tu
n'avez pas besoin de redémarrer le serveur pour que les modifications de code prennent effet. Cependant, certaines actions
comme l'ajout de fichiers ne déclenche pas de redémarrage, vous devrez donc redémarrer le serveur dans ces
Cas.

La compilation des fichiers de traduction redémarre désormais également le serveur de développement.

Si vous utilisez Linux et installez pyinotifier, les signaux du noyau seront utilisés pour le rechargement automatique
le serveur (plutôt que d'interroger les horodatages de modification de fichier chaque seconde). Cela offre
meilleure évolutivité vers de grands projets, réduction du temps de réponse à la modification du code, plus
détection robuste des changements et réduction de l'utilisation de la batterie.

pyinotifier le soutien a été ajouté.

Lorsque vous démarrez le serveur, et à chaque fois que vous modifiez le code Python pendant que le serveur est
en cours d'exécution, le serveur vérifiera l'ensemble de votre projet Django pour les erreurs (voir le choisissez
commander). Si des erreurs sont trouvées, elles seront imprimées sur la sortie standard, mais cela ne sera pas
arrêter le serveur.

Vous pouvez exécuter autant de serveurs que vous le souhaitez, à condition qu'ils soient sur des ports séparés. Seulement
exécuter Django-admin serveur d'exécution plus d'une fois.

Notez que l'adresse IP par défaut, 127.0.0.1, n'est pas accessible depuis d'autres machines sur votre
réseau. Pour rendre votre serveur de développement visible par les autres machines du réseau, utilisez
sa propre adresse IP (par ex. 192.168.2.1) ou 0.0.0.0 or :: (avec IPv6 activé).

Vous pouvez fournir une adresse IPv6 entourée de crochets (par exemple [200a :: 1] : 8000). Cette volonté
activer automatiquement la prise en charge d'IPv6.

Un nom d'hôte contenant uniquement des caractères ASCII peut également être utilisé.

Si la fichiers statiques l'application contrib est activée (par défaut dans les nouveaux projets) le serveur d'exécution commander
sera remplacé par le sien serveur d'exécution commander.

If émigrer n'a pas été exécuté auparavant, la table qui stocke l'historique des migrations est
créé à la première exécution de serveur d'exécution.

--pas de rechargement

Utilisez l'option --pas de rechargement option pour désactiver l'utilisation du rechargement automatique. Cela signifie n'importe quel Python
les modifications de code que vous apportez pendant que le serveur est en cours d'exécution pas prend effet si le particulier
Les modules Python ont déjà été chargés en mémoire.

Exemple d'utilisation:

serveur d'exécution django-admin --noreload

--pas de lecture

Le serveur de développement est multithread par défaut. Utilisez le --pas de lecture Option de
désactiver l'utilisation du threading dans le serveur de développement.

--ipv6, -6

Utilisez l'option --ipv6 (ou plus court -6) option pour dire à Django d'utiliser IPv6 pour le développement
serveur. Cela change l'adresse IP par défaut de 127.0.0.1 à :: 1.

Exemple d'utilisation:

serveur d'exécution django-admin --ipv6

Exemples of en utilisant différent ports et adresses
Port 8000 sur l'adresse IP 127.0.0.1:

serveur d'exécution django-admin

Port 8000 sur l'adresse IP 1.2.3.4:

serveur d'exécution django-admin 1.2.3.4:8000

Port 7000 sur l'adresse IP 127.0.0.1:

serveur d'exécution django-admin 7000

Port 7000 sur l'adresse IP 1.2.3.4:

serveur d'exécution django-admin 1.2.3.4:7000

Port 8000 sur l'adresse IPv6 :: 1:

serveur d'exécution django-admin -6

Port 7000 sur l'adresse IPv6 :: 1:

serveur d'exécution django-admin -6 7000

Port 7000 sur l'adresse IPv6 2001:0db8:1234:5678::9:

django-admin runserver [2001:0db8:1234:5678::9]:7000

Port 8000 sur l'adresse IPv4 de l'hôte localhost:

django-admin serveur d'exécution localhost : 8000

Port 8000 sur l'adresse IPv6 de l'hôte localhost:

django-admin serveur d'exécution -6 hôte local : 8000

Service statique fichiers avec le développant serveur
Par défaut, le serveur de développement ne sert aucun fichier statique pour votre site (tel que
Fichiers CSS, images, choses sous MEDIA_URL et ainsi de suite). Si vous souhaitez configurer Django
pour servir des médias statiques, lisez /comment/fichiers-statiques/index.

coquille
Django-admin coquille

Démarre l'interpréteur interactif Python.

Django utilisera IPython or bpython si l'un ou l'autre est installé. Si vous avez une coquille riche
installé mais que vous voulez forcer l'utilisation de l'interpréteur Python "plain", utilisez le --plaine option,
ainsi:

shell django-admin --plain

Si vous souhaitez spécifier IPython ou bpython comme interpréteur si vous avez
les deux installés, vous pouvez spécifier une interface d'interprétation alternative avec le -i or
--interface des options comme ceci :

IPython :

shell django-admin -i ipython
shell django-admin --interface ipython

bpython :

shell django-admin -i bpython
shell django-admin --interface bpython

Lorsque l'interpréteur interactif Python "simple" démarre (que ce soit parce que --plaine était
spécifié ou parce qu'aucune autre interface interactive n'est disponible) il lit le script
signalé par le PYTHONSTARTUP variable d'environnement et la ~/.pythonrc.py scénario. Si tu
ne souhaite pas ce comportement, vous pouvez utiliser le --pas de démarrage option. par exemple:

shell django-admin --plain --no-startup

afficher les migrations [ [ ]]
Django-admin afficher les migrations

Affiche toutes les migrations d'un projet.

--liste, -l

Le --liste L'option répertorie toutes les applications que Django connaît, les migrations disponibles pour
chaque application, et si chaque migration est appliquée ou non (marquée par un [X] à côté de la
nom de la migration).

Les applications sans migrations sont également répertoriées, mais ont non migratoires) imprimé sous eux.

--planifier, -p

Le --planifier L'option affiche le plan de migration que Django suivra pour appliquer les migrations. Tout
les étiquettes d'application fournies sont ignorées car le plan peut aller au-delà de ces applications. Pareil que
--liste, les migrations appliquées sont marquées par un [X]. Pour une verbosité de 2 et plus, tout
les dépendances d'une migration seront également affichées.

sql <étiquette_app étiquette_app ...>
Django-admin sql

Imprime les instructions SQL CREATE TABLE pour le(s) nom(s) d'application donné(s).

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

sqlall <étiquette_app étiquette_app ...>
Django-admin sqlall

Imprime la CREATE TABLE et les instructions SQL de données initiales pour le(s) nom(s) d'application donné(s).

Référez-vous à la description de sqlpersonnalisé pour une explication sur la façon de spécifier les données initiales.

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

Le sql* les commandes de gestion respectent désormais les permettre_migrate() méthode de DATABASE_ROUTERS.
Si vous avez des modèles synchronisés avec des bases de données autres que celles par défaut, utilisez le --base de données indicateur pour obtenir SQL pour
ces modèles (auparavant, ils étaient toujours inclus dans la sortie).

sqlclear <étiquette_app étiquette_app ...>
Django-admin sqlclear

Imprime les instructions SQL DROP TABLE pour le(s) nom(s) d'application donné(s).

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

sqlpersonnalisé <étiquette_app étiquette_app ...>
Django-admin sqlpersonnalisé

Imprime les instructions SQL personnalisées pour le ou les noms d'application donnés.

Pour chaque modèle dans chaque application spécifiée, cette commande recherche le fichier
/sql/ .sql, Où est le nom de l'application donné et
est le nom du modèle en minuscule. Par exemple, si vous avez une application nouvelles qui comprend un
Histoire modèle, sqlpersonnalisé tentera de lire un fichier news/sql/histoire.sql et l'ajouter au
sortie de cette commande.

Chacun des fichiers SQL, s'il est fourni, doit contenir du code SQL valide. Les fichiers SQL sont redirigés
directement dans la base de données une fois que toutes les instructions de création de table des modèles ont été
réalisé. Utilisez ce hook SQL pour apporter des modifications à la table ou insérer des fonctions SQL
dans la base de données.

Notez que l'ordre dans lequel les fichiers SQL sont traités n'est pas défini.

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

index sqldrop <étiquette_app étiquette_app ...>
Django-admin index sqldrop

Imprime les instructions SQL DROP INDEX pour le(s) nom(s) d'application donné(s).

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

sqlflush
Django-admin sqlflush

Imprime les instructions SQL qui seraient exécutées pour le affleurer commander.

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

sqlindex <étiquette_app étiquette_app ...>
Django-admin sqlindex

Imprime les instructions SQL CREATE INDEX pour le(s) nom(s) d'application donné(s).

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

sqlmigrer
Django-admin sqlmigrer

Imprime le SQL pour la migration nommée. Cela nécessite une connexion à la base de données active, qui
il utilisera pour résoudre les noms de contraintes ; cela signifie que vous devez générer le SQL par rapport à un
copie de la base de données sur laquelle vous souhaitez l'appliquer ultérieurement.

Notez que sqlmigrer ne colore pas sa sortie.

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle générer le SQL.

--en arrière

Par défaut, le SQL créé sert à exécuter la migration vers l'avant. Passe
--en arrière pour générer le SQL pour annuler l'application de la migration à la place.

sqlsequencereset <étiquette_app étiquette_app ...>
Django-admin sqlsequencereset

Imprime les instructions SQL pour réinitialiser les séquences pour le(s) nom(s) d'application donné(s).

Les séquences sont des index utilisés par certains moteurs de base de données pour suivre le prochain numéro disponible pour
champs automatiquement incrémentés.

Utilisez cette commande pour générer du SQL qui résoudra les cas où une séquence n'est pas synchronisée avec
ses données de champ incrémentées automatiquement.

Le --base de données L'option peut être utilisée pour spécifier la base de données pour laquelle imprimer le SQL.

migrations de courges
Django-admin migrations de courges

Écrase les migrations pour étiquette_app jusqu'à et y compris nom_migration en moins
migrations, si possible. Les migrations écrasées qui en résultent peuvent cohabiter avec les
ceux non écrasés en toute sécurité. Pour plus d'informations, veuillez lire migration-écrasement.

--pas d'optimisation

Par défaut, Django essaiera d'optimiser les opérations dans vos migrations pour réduire le
taille du fichier résultant. Passe --pas d'optimisation si ce processus échoue pour vous ou
créant des migrations incorrectes, mais veuillez également déposer un rapport de bogue Django sur le
comportement, car l'optimisation est censée être sûre.

application de démarrage [destination]
Django-admin application de démarrage

Crée une structure de répertoire d'application Django pour le nom d'application donné dans le répertoire actuel
ou la destination donnée.

Par défaut le répertoire créé contient un modèles.py fichier et d'autres fichiers de modèle d'application.
(Voir le source pour plus de détails.) Si seul le nom de l'application est donné, le répertoire de l'application
être créé dans le répertoire de travail courant.

Si la destination facultative est fournie, Django utilisera ce répertoire existant plutôt
que d'en créer un nouveau. Vous pouvez utiliser '.' pour désigner le répertoire de travail courant.

Par exemple :

django-admin startapp monapp /Utilisateurs/jezdez/Code/monapp

--modèle

Les --modèle option, vous pouvez utiliser un modèle d'application personnalisé en fournissant soit le chemin
vers un répertoire avec le fichier modèle d'application, ou un chemin vers un fichier compressé (.tar.gz,
.tar.bz2, . Tgz, .tbz, .zip) contenant les fichiers de modèle d'application.

Par exemple, cela rechercherait un modèle d'application dans le répertoire donné lors de la création du
monapplication app:

django-admin startapp --template=/Users/jezdez/Code/my_app_template monapp

Django accepte également les URL (http, https, ftp) aux archives compressées avec l'application
modèles, en les téléchargeant et en les extrayant à la volée.

Par exemple, en profitant de la fonctionnalité de Github pour exposer les référentiels sous forme de fichiers zip, vous
peut utiliser une URL comme :

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip monapplication

Lorsque Django copie les fichiers de modèle d'application, il restitue également certains fichiers via le
moteur de template : les fichiers dont les extensions correspondent au --extension Option (py par défaut)
et les fichiers dont les noms sont passés avec le --Nom option. La modèle aux contextes utilisé est :

· Toute option passée au application de démarrage commande (parmi les options prises en charge par la commande)

· nom de l'application -- le nom de l'application tel que transmis à la commande

· répertoire_app -- le chemin complet de l'application nouvellement créée

· version_docs -- la version de la documentation : 'dev' or '1 fois'

AVERTISSEMENT:
Lorsque les fichiers de modèle d'application sont rendus avec le moteur de modèle Django (par défaut
tous *.py fichiers), Django remplacera également toutes les variables de modèle parasites contenues. Pour
exemple, si l'un des fichiers Python contient une docstring expliquant un
fonction liée au rendu du modèle, cela peut entraîner un exemple incorrect.

Pour contourner ce problème, vous pouvez utiliser le balise de modèle templatetag pour "échapper" au
différentes parties de la syntaxe du modèle.

démarrerprojet [destination]
Django-admin démarrerprojet

Crée une structure de répertoire de projet Django pour le nom de projet donné dans le
répertoire ou la destination donnée.

Par défaut, le nouveau répertoire contient gérer.py et un package de projet (contenant un
settings.py et autres fichiers). Voir le modèle source pour en savoir plus.

Si seul le nom du projet est donné, le répertoire du projet et le package du projet seront
nommé et le répertoire du projet sera créé dans le fichier de travail actuel
répertoire.

Si la destination facultative est fournie, Django utilisera ce répertoire existant comme
répertoire du projet et créer gérer.py et le package de projet qu'il contient. Utilisation '.' à
désigne le répertoire de travail courant.

Par exemple :

django-admin startproject monprojet /Users/jezdez/Code/myproject_repo

Comme avec la application de démarrage commande, le --modèle l'option vous permet de spécifier un répertoire, un fichier
chemin ou URL d'un modèle de projet personnalisé. Voir le application de démarrage documentation pour plus de détails sur
formats de modèle de projet pris en charge.

Par exemple, cela rechercherait un modèle de projet dans le répertoire donné lors de la création
le mon projet projet:

django-admin startproject --template=/Users/jezdez/Code/my_project_template monprojet

Django accepte également les URL (http, https, ftp) aux archives compressées avec le projet
modèles, en les téléchargeant et en les extrayant à la volée.

Par exemple, en profitant de la fonctionnalité de Github pour exposer les référentiels sous forme de fichiers zip, vous
peut utiliser une URL comme :

django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip monprojet

Lorsque Django copie les fichiers de modèle de projet, il restitue également certains fichiers via le
moteur de template : les fichiers dont les extensions correspondent au --extension Option (py par défaut)
et les fichiers dont les noms sont passés avec le --Nom option. La modèle aux contextes utilisé est :

· Toute option passée au démarrerprojet commande (parmi les options prises en charge par la commande)

· nom du projet -- le nom du projet tel qu'il est passé à la commande

· répertoire_projet -- le chemin complet du projet nouvellement créé

· clef secrète -- une clé aléatoire pour le CLEF SECRÈTE mise

· version_docs -- la version de la documentation : 'dev' or '1 fois'

Veuillez également consulter le rendu avertissement comme mentionné pour application de démarrage.

base de données synchronisée
Django-admin base de données synchronisée

Obsolète depuis la version 1.7 : cette commande est obsolète au profit de la émigrer
commande, qui exécute à la fois l'ancien comportement et l'exécution des migrations. C'est maintenant
juste un alias pour cette commande.

Alias ​​pour émigrer.

tester <application or tester identifiant>
Django-admin tester

Exécute des tests pour tous les modèles installés. Voir /sujets/tests/index pour plus d'informations.

--failfast

Le --failfast L'option peut être utilisée pour arrêter l'exécution des tests et signaler immédiatement l'échec
après l'échec d'un test.

--testrunner

Le --testrunner L'option peut être utilisée pour contrôler la classe de testeur qui est utilisée pour
exécuter des tests. Si cette valeur est fournie, elle remplace la valeur fournie par le
TEST_RUNNER multiculturel.

--liveserver

Le --liveserver L'option peut être utilisée pour remplacer l'adresse par défaut où le serveur live
(utilisé avec LiveServerTestCase) devrait s'exécuter à partir de. La valeur par défaut est
localhost: 8081.

--keepdb

Le --keepdb L'option peut être utilisée pour préserver la base de données de test entre les exécutions de test. Cela a
l'avantage de sauter à la fois les actions de création et de destruction, ce qui diminue considérablement la
le temps d'exécuter des tests, en particulier ceux d'une grande suite de tests. Si la base de données de test ne
existent, il sera créé lors de la première exécution, puis conservé pour chaque exécution suivante. Tout
les migrations non appliquées seront également appliquées à la base de données de test avant d'exécuter le test
suite.

--sens inverse

Le --sens inverse L'option peut être utilisée pour trier les cas de test dans l'ordre inverse. Cela peut aider
dans les tests de débogage qui ne sont pas correctement isolés et qui ont des effets secondaires. regroupement by tester
classe est conservé lors de l'utilisation de cette option.

--debug-sql

Le --debug-sql l'option peut être utilisée pour activer SQL enregistrement pour les tests ratés. Si --verbosité
is 2, les requêtes lors des tests de réussite sont également générées.

serveur de test <luminaire luminaire ...>
Django-admin serveur de test

Exécute un serveur de développement Django (comme dans serveur d'exécution) en utilisant les données du ou des appareils donnés.

Par exemple, cette commande :

django-admin serveur de test mydata.json

... effectuerait les étapes suivantes :

1. Créez une base de données de test, comme décrit dans la-base-de-test.

2. Remplissez la base de données de test avec les données d'appareils des appareils donnés. (Pour en savoir plus sur
luminaires, voir la documentation pour charger les données au dessus de.)

3. Exécute le serveur de développement Django (comme dans serveur d'exécution), pointé sur ce nouveau
base de données de test au lieu de votre base de données de production.

Ceci est utile de plusieurs manières :

· Lorsque vous écrivez unité tests de la façon dont vos vues agissent avec certaines données de luminaire, vous pouvez
utilisé serveur de test pour interagir manuellement avec les vues dans un navigateur Web.

· Supposons que vous développiez votre application Django et que vous ayez une copie « vierge » d'un
base de données avec laquelle vous souhaitez interagir. Vous pouvez vider votre base de données dans un appareil
(en utilisant le vidage de données commande, expliquée ci-dessus), puis utilisez serveur de test pour faire fonctionner votre Web
application avec ces données. Avec cet arrangement, vous avez la possibilité de déconner
vos données de quelque manière que ce soit, sachant que quelles que soient les modifications que vous apportez aux données,
fait à une base de données de test.

Notez que ce serveur ne pas détecter automatiquement les modifications apportées à votre code source Python (comme
serveur d'exécution Est-ce que). Cependant, il détecte les modifications apportées aux modèles.

--adresse [Port nombre or adresse IP:port]

Utilisez --adresse pour spécifier un port différent, ou une adresse IP et un port, par rapport à la valeur par défaut de
127.0.0.1:8000. Cette valeur suit exactement le même format et sert exactement le même
fonctionner comme l'argument de la serveur d'exécution commander.

Exemples :

Pour exécuter le serveur de test sur le port 7000 avec luminaire1 et luminaire2:

serveur de test django-admin --addrport 7000 fixture1 fixture2
serveur de test django-admin fixture1 fixture2 --addrport 7000

(Les énoncés ci-dessus sont équivalents. Nous les incluons tous les deux pour démontrer qu'il
peu importe que les options viennent avant ou après les arguments de fixture.)

Pour fonctionner sur 1.2.3.4:7000 avec un tester fixation:

django-admin testserver --addrport 1.2.3.4:7000 test

Le --pas d'entrée Une option peut être fournie pour supprimer toutes les invites de l'utilisateur.

valider
Django-admin valider

Obsolète depuis la version 1.7 : Remplacé par le choisissez commander.

Valide tous les modèles installés (selon le INSTALLED_APPS réglage) et imprime
erreurs de validation à la sortie standard.

COMMANDES À CONDITION DE BY APPLICATIONS

Certaines commandes ne sont disponibles que lorsque le django.contrib application que met en oeuvre le point de vue de
a été activé. Cette section les décrit regroupés par leur application.

django.contrib.auth
changepassword
Django-admin changepassword

Cette commande n'est disponible que si Django protocoles d'authentification Système (django.contrib.auth) est
installé.

Permet de changer le mot de passe d'un utilisateur. Il vous invite à entrer deux fois le mot de passe de l'utilisateur
donné en paramètre. S'ils correspondent tous les deux, le nouveau mot de passe sera immédiatement modifié. Si
vous ne fournissez pas d'utilisateur, la commande tentera de changer le mot de passe dont le nom d'utilisateur
correspond à l'utilisateur actuel.

Utilisez l'option --base de données option pour spécifier la base de données à interroger pour l'utilisateur. Si ce n'est pas
fourni, Django utilisera le défaut base de données.

Exemple d'utilisation:

django-admin changer le mot de passe ringo

créersuperutilisateur
Django-admin créersuperutilisateur

Cette commande n'est disponible que si Django protocoles d'authentification Système (django.contrib.auth) est
installé.

Crée un compte de superutilisateur (un utilisateur qui a toutes les autorisations). Ceci est utile si vous avez besoin
pour créer un compte superutilisateur initial ou si vous devez générer par programme
comptes de superutilisateur pour votre (vos) site(s).

Lorsqu'elle est exécutée de manière interactive, cette commande demandera un mot de passe pour le nouveau superutilisateur
Compte. Lorsqu'il est exécuté de manière non interactive, aucun mot de passe ne sera défini et le compte de superutilisateur
ne pourra pas se connecter tant qu'un mot de passe n'aura pas été défini manuellement.

--Nom d'utilisateur

--e-mail

Le nom d'utilisateur et l'adresse e-mail du nouveau compte peuvent être fournis en utilisant le --Nom d'utilisateur
et --e-mail arguments sur la ligne de commande. Si l'un de ceux-ci n'est pas fourni,
créersuperutilisateur le demandera lors de l'exécution interactive.

Utilisez l'option --base de données option pour spécifier la base de données dans laquelle l'objet superutilisateur sera
enregistré.

Vous pouvez sous-classer la commande de gestion et remplacer get_input_data() si tu veux
personnaliser la saisie et la validation des données. Consultez le code source pour plus de détails sur l'existant
mise en œuvre et les paramètres de la méthode. Par exemple, cela peut être utile si vous avez un
Clé étrangère in CHAMPS OBLIGATOIRES et souhaitez autoriser la création d'une instance au lieu d'entrer
la clé primaire d'une instance existante.

django.contrib.gis
ignoble
Cette commande n'est disponible que si GéoDjango (django.contrib.gis) est installé.

Veuillez vous référer à son la description dans la documentation GeoDjango.

django.contrib.sessions
effacer les sessions
Django-admin effacer les sessions

Peut être exécuté en tant que tâche cron ou directement pour nettoyer les sessions expirées.

django.contrib.sitemaps
ping_google
Cette commande n'est disponible que si le Sitemaps cadre (django.contrib.sitemaps) est
installé.

Veuillez vous référer à son la description dans la documentation Sitemaps.

django.contrib.staticfiles
collecte statique
Cette commande n'est disponible que si le statique fichiers application
(django.contrib.staticfiles) est installé.

Veuillez vous référer à son la description dans le fichiers statiques Documentation.

trouver statique
Cette commande n'est disponible que si le statique fichiers application
(django.contrib.staticfiles) est installé.

Veuillez vous référer à son la description dans le fichiers statiques Documentation.

DEFAULT OPTIONS

Bien que certaines commandes puissent autoriser leurs propres options personnalisées, chaque commande permet le
options suivantes:

--pythonpath

Exemple d'utilisation:

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

Ajoute le chemin du système de fichiers donné au Python importer recherche chemin. Si ce n'est pas fourni,
Django-admin utilisera le PYTHONPATH variable d'environnement.

Notez que cette option est inutile dans gérer.py, car il se charge de régler le
Chemin Python pour vous.

--Les paramètres

Exemple d'utilisation:

django-admin migrer --settings=mysite.settings

Spécifie explicitement le module de paramètres à utiliser. Le module de paramètres doit être en Python
syntaxe du package, par exemple monsite.paramètres. Si ce n'est pas fourni, Django-admin utilisera le
DJANGO_SETTINGS_MODULE variable d'environnement.

Notez que cette option est inutile dans gérer.py, car il utilise settings.py du
projet en cours par défaut.

--trace

Exemple d'utilisation:

django-admin migrer --traceback

Par défaut, Django-admin affichera un simple message d'erreur chaque fois qu'un Erreur de commande se produit,
mais une trace de pile complète pour toute autre exception. Si vous spécifiez --trace, Django-admin
produira également une trace de pile complète lorsqu'un Erreur de commande est soulevé.

--verbosité

Exemple d'utilisation:

django-admin migrer --verbosity 2

Utilisez --verbosité pour spécifier la quantité d'informations de notification et de débogage qui
Django-admin devrait s'imprimer sur la console.

· 0 signifie pas de sortie.

· 1 signifie sortie normale (par défaut).

· 2 signifie une sortie verbeuse.

· 3 veux dire très sortie verbeuse.

--sans couleur

Exemple d'utilisation:

django-admin sqlall --no-color

Par défaut, Django-admin formatera la sortie à coloriser. Par exemple, les erreurs seront
sera imprimé sur la console en rouge et les instructions SQL seront mises en évidence par la syntaxe. Pour prévenir
ceci et avoir une sortie en texte brut, passez le --sans couleur option lors de l'exécution de votre commande.

COMMUNE OPTIONS

Les options suivantes ne sont pas disponibles sur toutes les commandes, mais elles sont communes à un certain nombre
de commandes.

--base de données

Utilisé pour spécifier la base de données sur laquelle une commande va opérer. S'il n'est pas spécifié, ce
l'option sera par défaut un alias de défaut.

Par exemple, pour vider les données de la base de données avec l'alias maître:

django-admin dumpdata --database=maître

--exclure

Exclure une application spécifique des applications dont le contenu est sorti. Pour
exemple, pour exclure spécifiquement les auth application à partir de la sortie de dumpdata, vous
appellerait :

django-admin dumpdata --exclude=auth

Si vous souhaitez exclure plusieurs applications, utilisez plusieurs --exclure directives :

django-admin dumpdata --exclude=auth --exclude=contenttypes

--lieu

Utilisez l'option --lieu or -l option pour spécifier les paramètres régionaux à traiter. Si non fourni tout
les paramètres régionaux sont traités.

--pas d'entrée

Utilisez l'option --pas d'entrée option pour supprimer toutes les invites de l'utilisateur, telles que « Êtes-vous sûr ? »
messages de confirmation. Ceci est utile si Django-admin est exécuté sans surveillance,
script automatisé.

EXTRA RAFFINEMENTS

Syntaxe coloration
Le Django-admin / gérer.py les commandes utiliseront une sortie assez codée par couleur si votre terminal
prend en charge la sortie couleur ANSI. Il n'utilisera pas les codes de couleur si vous dirigez la commande
sortie vers un autre programme.

Sous Windows, la console native ne prend pas en charge les séquences d'échappement ANSI donc par défaut
il n'y a pas de sortie couleur. Mais vous pouvez installer le ANSICON outil tiers, le Django
les commandes détecteront sa présence et utiliseront ses services pour colorer la sortie juste
comme sur les plates-formes Unix.

Les couleurs utilisées pour la coloration syntaxique peuvent être personnalisées. Django est livré avec trois couleurs
palettes :

· entrepôts, adapté aux terminaux qui affichent du texte blanc sur fond noir. C'est le
palette par défaut.

· lumière, adapté aux terminaux qui affichent du texte noir sur fond blanc.

· sans couleur, qui désactive la coloration syntaxique.

Vous sélectionnez une palette en définissant un DJANGO_COLORS variable d'environnement pour spécifier le
palette que vous souhaitez utiliser. Par exemple, pour spécifier le lumière palette sous Unix ou OS/X
Shell BASH, vous devez exécuter ce qui suit dans une invite de commande :

export DJANGO_COLORS="lumière"

Vous pouvez également personnaliser les couleurs utilisées. Django spécifie un certain nombre de rôles dans
quelle couleur est utilisée :

· erreur - Une erreur majeure.

· avis - Une erreur mineure.

· champ_sql - Le nom d'un champ modèle en SQL.

· sql_coltype - Le type d'un champ de modèle en SQL.

· mot_clé_sql - Un mot clé SQL.

· table_sql - Le nom d'un modèle en SQL.

· http_info - Une réponse du serveur d'information HTTP 1XX.

· http_succès - Une réponse du serveur 2XX HTTP Success.

· http_not_modified - Une réponse du serveur 304 HTTP non modifié.

· http_redirection - Une réponse du serveur de redirection HTTP 3XX autre que 304.

· http_not_found - Une réponse du serveur 404 HTTP Not Found.

· http_bad_request - Une réponse du serveur 4XX HTTP Bad Request autre que 404.

· erreur_serveur_http - Une réponse d'erreur du serveur HTTP 5XX.

Chacun de ces rôles peut se voir attribuer une couleur de premier plan et d'arrière-plan spécifique, à partir du
liste suivante :

· noir

· rouge

· et une transition qui soit juste.

· jaune

· Bleu

· magenta

· cyan

· blanc

Chacune de ces couleurs peut ensuite être modifiée en utilisant les options d'affichage suivantes :

· goupille

· souligner

· cligner des yeux

· inverser

· cacher

Une spécification de couleur suit l'un des modèles suivants :

· rôle=fg

· rôle=fg/bg

· rôle=fg,option,option

· rôle=fg/bg,option,option

où rôle de l' est le nom d'un rôle de couleur valide, fg est la couleur de premier plan, bg est le
couleur de fond et chaque option est l'une des options de modification des couleurs. Couleur multiple
les spécifications sont ensuite séparées par un point-virgule. Par exemple:

export DJANGO_COLORS="error=jaune/bleu,blink;notice=magenta"

spécifierait que les erreurs s'affichent en clignotant jaune sur bleu, et les avis
affiché en magenta. Tous les autres rôles de couleur seraient laissés non colorés.

Les couleurs peuvent également être spécifiées en étendant une palette de base. Si vous mettez un nom de palette dans un
spécification des couleurs, toutes les couleurs impliquées par cette palette seront chargées. Donc:

export DJANGO_COLORS="light;error=jaune/bleu,blink;notice=magenta"

préciserait l'utilisation de toutes les couleurs de la palette de couleurs claires, sauf pour les couleurs
pour les erreurs et les avis qui seraient remplacés comme spécifié.

Prise en charge de la sortie codée par couleur à partir de Django-admin / gérer.py utilitaires sous Windows par
s'appuyant sur l'application ANSICON a été ajouté dans Django 1.7.

Frapper achèvement
Si vous utilisez le shell Bash, envisagez d'installer le script de complétion bash Django, qui
vit à suppléments/django_bash_completion dans la distribution Django. Il permet
tabulation de Django-admin et gérer.py commandes, vous pouvez donc, par exemple...

· Taper Django-admin.

· Appuyez sur [TAB] pour voir toutes les options disponibles.

· Taper sql, puis [TAB], pour voir toutes les options disponibles dont les noms commencent par sql.

See /howto/custom-management-commandes pour savoir comment ajouter des actions personnalisées.

django.core.management.call_command(nom, *arguments, **options)

Pour appeler une commande de gestion à partir du code, utilisez appel_commande.

prénom le nom de la commande à appeler.

*arguments une liste d'arguments acceptés par la commande.

** options
options nommées acceptées sur la ligne de commande.

Exemples :

à partir de la gestion des importations de django.core
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)

Notez que les options de commande qui ne prennent aucun argument sont passées en tant que mots-clés avec Vrai or
Faux, comme vous pouvez le voir avec le Interactif option ci-dessus.

Les arguments nommés peuvent être transmis en utilisant l'une des syntaxes suivantes :

# Similaire à la ligne de commande
management.call_command('dumpdata', '--natural-foreign')

# Argument nommé similaire à la ligne de commande moins les tirets initiaux et
# avec des tirets internes remplacés par des traits de soulignement
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` est la variable de destination de l'option
management.call_command('dumpdata', use_natural_foreign_keys=True)

La première syntaxe est désormais supportée grâce à des commandes de gestion utilisant le argumenter module.
Pour la deuxième syntaxe, Django a précédemment transmis le nom de l'option tel quel à la commande, maintenant
il utilise toujours le moins nom de la variable (qui peut être ou non le même que l'option
Nom).

Les options de commande qui prennent plusieurs options reçoivent une liste :

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

SORTIE REDIRECTION

Notez que vous pouvez rediriger les flux de sortie et d'erreur standard car toutes les commandes prennent en charge le
Stdout et stderr option. Par exemple, vous pourriez écrire :

avec open('/tmp/command_output') comme f :
management.call_command('dumpdata', stdout=f)

Utilisez django-admin en ligne en utilisant les services onworks.net