Prenez les commandes de votre projet Django

Django propose un certain nombre de commandes. Vous connaissez surement tous runserver pour lancer le serveur web de développement ou syncdb pour générer la base de données. Voici quelques autres commandes moins connus mais qui peuvent se révéler utile et en bonus comment créer vos propres commandes.

Connaître le SQL utilisé pour générer la base de données

La commande sqlall permet de connaître les requêtes exécutées pour la création de la base de données.

Si vous utilisez south (et si ca n'est pas encore le cas, vous devriez) pour gérer les migrations de la base, vous avez peut être besoin de connaître le SQL utilisé lors d'une migration. Cela peut se révéler très pratique pour debugger un problème sur une migration. Dans ce cas, la commande suivante vous révèle le SQL utilisé.

python manage.py migrate --db-dry-run --verbosity=2

L'option db-dry-run charge et exécute les migrations sans accéder à la base de données. C'est un moyen de tester que le code est correct. L'option verbosity=2 permet de voir les requêtes SQL utilisés. Notez que la migration n'est pas marquée comme exécutée.

Import et Export de données

Django propose deux commandes pour exécuter ces tâches facilement.

python manage.py dumpdata --indent=1 [app1 app2.model1 ...]  1> monfichier.json

python manage.py loaddata monfichier.json

Un problème peut se poser lors de l'export (dumpdata) et le réimport (loaddata). En effet, ces commandes utilisent les identifants pour faire le lien avec un champ foreignkey ou manytomany. Et cela peut causer quelques surprises.

Le cas typique survient lorsqu'un modèle fait référence à des contenttypes. les contenttypes étant regénérés lors de la création de la base, on peut très bien avoir pour un même contenttype des identifiants différents lors de l'export et de l'import. Il suffit pour cela d'avoir ajouté quelques nouveaux modèles ou applications au projet.

Depuis la version 1.2, Django propose un mécanisme appelé "natural keys" pour gérer ce problème. L'idée est simple: fournir pour son modèle un identifiant explicite à partir de certains champs. Par exemple, les natural keys d'un contenttype sont le nom de m'application et le nom du modèle. Je vous recommande un petit tour par la doc pour en savoir plus.

Il est alors possible d'utiliser les naturalkeys plutôt que l'identifiant pour générer un dump de la base. Il suffit de passer l'option --natural à la commande dumpdata. La commande loaddata se débrouillera ensuite pour recréer les foreignkeys à l'aide des naturalkeys.

Entrez dans le code lors d'une exception

L'application django_extension propose quelques améliorations à Django. Elle rajoute en particulier des commandes parmi lesquelles la commande runserver_plus se révèle très intéressante.

runserver_plus est une version améliorée du serveur de développement lancé habituellement par la commande runserver. Lorsqu'une erreur se produit (entendez une exception non catchée), runserver_plus affiche une page d'erreur un peu plus joli. Mais surtout, en consultant la pile d'appel, on peut visualiser le code ou bien ouvrir une console python et ainsi interagir avec l'application.

Je ne connais pas encore très bien django_extension que j'utilises depuis peu mais cette application me parait très bien faite et indispensable dans la boîte à outils de chaque projet.

Pour aller plus loin avec cette application, je vous recommande de visionner le screencast suivant et de découvrir d'autres commandes telles que shell_plus pour automaiquement importer les modèles dans un shell ou graph_models pour générer un diagramme de base de données.

Créez vos propres commandes

django_extensions propose aussi une commande create_command qui permet de créer facilement vos propres commandes. En fait cette commande, génère automatiquement les répertoires et fichiers nécessaires ainsi qu'un squellete de classe pour la commande.

python manage.py create_command my_app

Dans l'application my_app, un package management a été généré. Ce répertoire contient un fichier sample.py qu'il faut renommer du nom de la commande souhaitée, par exemple hello_world.py

On édite alors le code et redéfinit la fonction handle qui correspond au code appelé lors de la commande. On peut aussi définir un message d'aide qui sera affiché par la commande python manage.py help hello_world

from django.core.management.base import BaseCommand
class Command(BaseCommand):
   help = "This command print hello world message"
   def handle(self, *args, **options):
   print 'Hello World'
   print 'args:', args
   print 'options:', options

La méthode handle prend 2 arguments: options qui contiendra tout ce qui est passé sur la ligne de commande préfixé par '--'. Cela correspond à des options par défaut telles que le fichiers settings ou le path à utiliser. args contiendra tout ce qui est passé en ligne de commande sans le préfixe --.

Ainsi, python manage.py hello_world --verbosity=2 toto titi affichera le résultat suivant:

Hello World
args: ('toto', 'titi')
options: {'pythonpath': None, 'verbosity': '2', 'traceback': None, 'settings': None}

Avec tout cela, vous pouvez prendre les commandes de votre projet Django.

Python  Django  Posté le 1 septembre 2011 par - Commentez cet article - Partagez