Le livre de

adminindex [nomappli nomappli ?]

Affiche l’extrait de gabarit admin-index pour les noms d’application donnés. Utilisez l’extrait de gabarit admin-index si vous voulez personnaliser l’ergonomie de votre page d’accueil d’administrateur.

createcachetable [nomtable]

Créer une table cache appelée nomtable pour utilisation avec le cache de base de donnée à l’arrière plan. Consultez le chapitre 13 pour des détails au sujet de la mise en cache.

dbshell

Lance le client en ligne de commande pour le moteur de base de données spécifié dans votre paramètre DATABASE_ENGINE, avec les paramètres de connection précisés dans les paramètres DATABASE_USER, DATABASE_PASSWORD, et ainsi de suite.

• Pour PostgreSQL, lance le client en ligne de commande psql.
• Pour MySQL, lance le client en ligne de commande mysql.
• Pour SQLite, lance le client en ligne de commande sqlite3.

Cette commande considère que les programmes sont présents dans votre PATH de façon à ce qu’un simple appel du nom de programme (psql, mysql, ou sqlite3) trouve le programme à la bonne place. Il n’est pas possible de préciser manuellement l’emplacement du programme.

diffsettings

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

Les paramètres qui n’apparaissent pas dans ceux par défaut sont suivis par "###". Par exemple, les paramètres par défaut ne définissent pas ROOT_URLCONF, donc ROOT_URLCONF est suivi par "###" dans la sortie de diffsettings.

Notez que les paramètres par défaut de Django résident dans django.conf.global_settings, si toutefois vous étiez curieux de voir la liste complète des paramètres par défaut.

dumpdata [nomappli nomappli ?]

Affiche sur la sortie standard toutes les données de la base associées avec la ou les applications nommées.

Par défaut, la base de données sera enregistrée au format JSON. Si vous voulez que la sortie soit dans un autre format, utilisez l’option --format (par exemple, format=xml). Vous pouvez spécifier tout arrière-plan de sérialisation (y compris tout arrière-plan de sérialisation indiqués dans le paramètre SERIALIZATION_MODULES). L’option --indent peut être utilisée pour améliorer l’affichage de la sortie.

Si aucun nom d’application n’est précisé, toutes les applications installées seront enregistrées.

La sortie de dumpdata peut être utilisée comme entrée de loaddata.

flush

Renvoie la base de donnée à l’état dans lequel elle se trouvait immédiatement après que syncdb soit exécutée. Ceci signifie que toutes les données seront retirées de la base de données, que tout les gestionnaires de postsynchronisation seront de nouveau exécutés, et que la garniture initial_data sera réinstallée.

inspectdb

Examine les tables de la base de données qui sont pointées par le paramètre DATABASE_NAME et affiche un module de modèle Django (un fichier models.py) sur la sortie standard.

Utilisez cela si vous avez une base de données existante avec laquelle vous voulez utiliser Django. Le script inspectera la base de données puis créera un modèle pour chacunes des tables présentes.

Comme vous pouvez l’attendre, les modèles crées auront un attribut pour chaque champs dans la table. Notez que inspectdb à quelques cas particuliers dans son rendu des noms de champ:

• If inspectdb ne peut assurer la correspondance entre un type de colonne et un type de modèle de champ, elle utilisera TextField et insérera le commentaire Python 'Ce type de champ est une supposition.' près du champ du modèle généré.
• Si le nom de colonne de la base de données est un mot Python réservé (tel que 'pass', 'class', ou 'for'), inspectdb ajoutera '_field' au nom de l’attribut. Par exemple, si une table possède une colonne 'for', le modèle généré aura un champ 'for_field', avec l’attribut db_column fixé à 'for'. inspectdb insérera le commentaire Python 'Champ renommé car il s'agissait d'un mot réservé par Python.' à côté du champ.

Cette fonctionnalité est considérée comme un raccourcis, pas comme une génération de modèle définitive. Après l’avoir lancé, vous voudrez explorer les modèles générés par vous même pour appliquer des personnalisations. En particulier, vous devrez réarranger les modèles de façon à ce que les modèles ayant des relations soient correctement ordonnés.

Les clefs primaires sont automatiquement examinées pour PostgreSQL, MySQL, et SQLite, auquels cas Django place primary_key=True où cela est nécessaire.

inspectdb fonctionne avec PostgreSQL, MySQL, et SQLite. La détection de clef étrangère fonctionne uniquement pour PostgreSQL et avec certains types de tables pour MySQL.

loaddata [garniture garniture ?]

Recherche et charge le contenu de la garniture nommée depuis la base de données.

Une garniture est une collection de fichiers qui contient le contenu sérilaisé de la base de données. Chaque garniture à un nom unique; cependant, les fichiers qui comprennent la garniture peuvent être distribués sur de multiples répertoires, dans de multiples applications.

Django cherchera les garnitures dans trois emplacements:

• Dans le répertoire fixtures de chaque aplication installées.
• Dans tout répertoire indiqués dans le paramètre FIXTURE_DIRS.
• Dans le chemin litéral indiqué par la garniture.

Django chargera parmi toutes les garnitures qu’il trouve dans ces emplacements celles qui correspondent aux noms des garnitures fournies.

Si la garniture nommée présente une extension de fichier, seules les garnitures de ce type seront chargées Par exemple, la commande suivante:

django-admin.py loaddata mydata.json

chargera uniquement les garnitures JSON appellée mydata. L’extension de la garniture doit correspondre au nom enregistré d’un serialiseur (par exemple, json ou xml).

Si vous omettez l’extension, Django cherchera tous les types de garnitures disponibles pour une garniture correspondante. Par exemple, la commande suivante:

django-admin.py loaddata mydata

cherchera toute garniture de type de garniture nommé mydata. Si un dossier de garnitures contient mydata.json, cette garniture sera chargée en tant que garniture JSON. Cependant, si deux garnitures du même nom mais de type de garniture différent sont rencontrées (par exemple, si mydata.json et mydata.xml se trouvent dans le même répertoire de garnitures), l’installation des garnitures sera sera stoppé, et toute donnée se trouvant dans l’appel à loaddata sera retiré de la base de données.

Les garnitures qui sont nommées peuvent inclures des composants répertoire. Ces répertoires seront inclus dans le chemin de recherche. La commande suivante, par exemple:

django-admin.py loaddata foo/bar/mydata.json

recherchera <appname>/fixtures/foo/bar/mydata.json pour chaque applications installées, <dirname>/foo/bar/mydata.json pour chaque répertoires de FIXTURE_DIRS, et pour le chemin littéral foo/bar/mydata.json.

Notez que l’ordre dans lequel des fichiers de garnitures sont traités est indéfini. Cependant, toute donnée de garnitures étant installée comme une transaction unique, les données de garnitures peuvent donc référencer des données d’une autre garniture. Si le moteur de base de données supporte les contraintes au niveau des lignes, ces contraintes seront vérifiées à la fin de la transaction.

La commande dumpdata peut être utilisé pour générer l’entrée de loaddata.

MySQL et les garnitures

Malheureusement, MySQL n’est pas capable de supporter totalement toutes les possibilités des garnitures Django. Si vous utilisez des tables MyISAM, MySQL ne supporte pas les transactions ou les contraintes, vous n’aurez donc pas de retour possible si de multiples fichiers de transaction sont trouvés, ou de validation des données de garniture. Si vous utilisez des tables InniDB, vous ne pourrez avoir aucune références arrière dans vos fichiers de données - MySQL ne fournit pas un mécanisme pour le report de vérification des contraintes de lignes jusqu’à ce que la transaction soit terminée.

reset [nomappli nomappli ?]

Exécute l’équivalent de sqlreset pour les noms d’applications donnés.

runfcgi [options]

Démarre un jeu de processus FastCGI utilisable avec n’importe quel serveur web supportant le protocol FastCGI. Consultez le chapitre 20 pour en savoir plus sur le déploiement sous FastCGI.

Cette commande nécessite le module Python FastCGI de flup (http://www.djangoproject.com/r/flup/).

runserver [numéro de port optionnel, ou addresseip:port]

Démarre un serveur de développement web sur la machine locale. Par defaut, le serveur écoute sur le port 8000 pour l’adresse IP 127.0.0.1. Vous pouvez préciser une addresse IP et un numéro de port explicitement.

Si vous lancez ce script en tant qu’utilisateur ayant des privilèges normaux (recommandé), vous n’aurez pas accès au démarrage d’un port sur un faible numéro. Les petits numéros de port sont réservés au super utilisateur (root).

Le serveur de développement recharge automatiquement le code Python pour chaque requête, selon les besoins. Vous n’avez pas à redémarrer le serveur pour que les changements apportés au code prennent effet.

Lorsque vous démarrez le serveur, et à chaque fois que vous modifiez le code Python pendant que le serveur tourne, le serveur validera tous vos modèles installés. (consultez la section à venir sur la commande validate). Si le validateur rencontre des erreurs, il les affichera sur la sortie standard, mais n’arrêtara pas le serveur.

Vous pouvez lancer autant de serveurs que vous le voulez, dès lors qu’ils utilisent des ports différents. Exécutez simplement django-admin.py runserver plus d’une fois.

Notez que l’adresse IP par défaut, 127.0.0.1, n’est pas accèssible depuis d’autre machines sur votre réseau. Pour rendre visible votre serveur de développement aux autres machines du réseau, utilisez sa propre adresse IP (par exemple, 192.168.12.1) ou 0.0.0.0.

Par exemple, pour lancer le serveur sur le port 7000 à l’adresse 127.0.0.1, utilisez ceci:

django-admin.py runserver 7000

Ou pour lancer le serveur sur le port 7000 sur l’adresse IP 1.2.3.4, utilisez:

django-admin.py runserver 1.2.3.4:7000

django-admin.py runserver --noreload

shell

Démarre l’interpréteur interactif Python.

Django utilisera IPython (http://ipython.scipy.org/) s’il est installé. Si vous avez IPython d’installé et que vous vouliez forcer l’utilisation de l’interpréteur Python natif, utilisez l’option --plain, comme ceci:

django-admin.py shell --plain

sql [nomappli nomappli ?]

Affiche les instructions SQL CREATE TABLE pour les noms d’applications donnés.

sqlall [nomappli nomappli ?]

Affiche CREATE TABLE et les instruction SQL des données initiales pour les noms d’application données.

Reportez vous à la description de sqlcustom pour une explication sur la façon de préciser les données initiales.

sqlclear [nomappli nomappli ?]

Affiche les instructions SQL DROP TABLE pour les noms d’applications donnés.

sqlcustom [nomappli nomappli ?]

Affiche les instructions SQL personnalisées pour les noms d’applications donnés.

Pour chaque modèle dans chacunes des applications spécifiées, cette commande consulte le fichier <appname>/sql/<modelname>.sql, où <appname> est le nom de l’application indiquée et <modelname> est le nom du modèle en bas de casse. Par exemple, si vous avez une application news qui propose le modèle Story, sqlcustom tentera de lire un fichier news/sql/story.sql et lui ajoutera la sorite de cette commande.

Chaque fichier SQL, si précisé, est censé contenir du SQL valide. Les fichiers SQL sont directement appliqués dans la base de données après que chaque instruction de création des tables de modèle ait été exécutées. Utilisez cette accroche SQL pour faire toutes modifications sur les tables, ou inserer n’importe quelle fonction SQL dans la base de données.

Notez que l’ordre du traitement des fichiers SQL n’est pas défini.

sqlindexes [nomappli nomappli ?]

Prints the CREATE INDEX SQL statements for the given app names.

sqlreset [nomappli nomappli ?]

Affiche le SQL DROP TABLE, puis le SQL CREATE TABLE, pour les noms d’applications fournis.

sqlsequencereset [nomappli nomappli ?]

Affiche les instructions SQL pour réinitialiser les séquences des applications dont le nom est fourni.

Vous aurez besoin de ce SQL seulement si vous utilisez PostgreSQL et que vous ayez inséré des données manuellement. Lorsque vous faîte cela, les séquences de clef primaire peuvent vous désynchroniser de ce qui se trouve dans la base de données, le SQL généré par cette commande le nettoiera.

startapp [nomappli]

Creates a Django application directory structure for the given app name in the current directory.

startproject [nomprojet]

Créer dans le répertoire courant une structure de répertoire pour un projet Django selon le nom du projet fourni.

syncdb

Créer les tables dans la base de données pour toutes les applications situées dans INSTALLED_APPS si ces tables n’ont pas déjà été crées.

Utilisez cette commande lorsque vous avez ajoutez de nouvelles applications à votre projet et que vous vouliez les installer dans la base de données. Ceci comprends toutes les applications livrées avec Django qui sont installées par défaut dans INSTALLED_APPS. Lorsque vous démarrez un nouveau projet, lancez cette commande pour installer les applications par défaut.

Si vous installez l’application django.contrib.auth, syncdb vous donnera la possibilité de créer un super utilisateur immédiatement. syncdb cherchera et installera aussi toutes garnitures nommées initial_data. Consultez la documentation de loaddata pour les détails sur la spécification des fichiers de garniture de données.

test

Découvre et lance les tests pour tous les modèles installés. Les tests étaient toujours en développement lorsque ce livre à été ecrit, aussi pour en savoir plus vous devrez lire la documentation en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/testing/.

validate

Valide tous les modèles installés (selon le paramètre INSTALLED_APPS) et affiche les erreurs de validation sur la sortie standard.

—settings

Exemple d’utilisation:

django-admin.py syncdb --settings=mysite.settings

Précise explicitement le module de paramètres à utiliser. Le module de paramètres doit se conformer à la syntaxe des paquets Python (par exemple, mysite.settings). S’il n’est pas fourni, django-admin.py utilisera la variable d’environnement DJANGO_SETTINGS_MODULE.

Notez que cette option n’est pas nécessairement dans manage.py, car elle se préoccupe de paramétrer DJANGO_SETTINGS_MODULE pour vous.

—pythonpath

Exemple d’utilisation:

django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject'

Ajoute le chemin précisé au chemin de recherche utilisé par Python pour les imports. Si rien n’est précisé, django-admin.py utilisera la variable d’environnement PYTHONPATH.

Notez que cette option n’est pas nécessairement dans manage.py, car elle se préoccupe de paramétrer le PATH Python pour vous.

—format

Exemple d’utilisation:

django-admin.py dumpdata --format=xml

Précise le format de sortie qui sera utilisé. Le nom fourni doit être le nom d’un sérialiseur enregistré.

—help

Affiche un message d’aide qui inclu une brève liste de toutes les actions et options disponibles.

—indent

Exemple d’utilisation:

django-admin.py dumpdata --indent=4

Précise le nombre d’espaces qui seront utilisés pour l’indentation lors des sorties formatées. Par défaut, la sortie ne sera pas formatée. Le formatage sera activé seulement si l’option indent est fournie.

—noinput

Indique que vous n’aurez pas d’invite pour les entrées. Ceci est utile si le script django-admin est a exécuter comme un script automatisé, sans surveillance.

—noreload

Désactive l’usage du rechargement automatique pendant le fonctionnement du serveur de développement.

—version

Affiche la version de Django utilisée.

Exemple de sortie:

0.9.1
0.9.1 (SVN)

—verbosity

Exemple d’utilisation:

django-admin.py syncdb --verbosity=2

Détermine le volume des avertissements et des informations de débugage qui s’afficheront sur la console. 0 correspond à aucune sortie, 1 à une sortie normale, 2 à une sortie verbeuse.

—adminmedia

Exemple d’utilisation:

django-admin.py --adminmedia=/tmp/new-admin-style/

Indique à Django l’endroit ou trouver les divers fichiers CSS et Javascript pour l’interface d’administration lorsque vous utilisez le serveur de développement. Normallement ces fichiers sont servis depuis l’arborescence des sources de Django, mais puisque certains graphistes personnalisent ces fichiers pour leurs sites, cette option vous permet de tester des versions personnalisées.

<< précédent ◊ suivant >>