Setup de la base de données avec Django

La prochaine étape est de mettre la base de donnée en place. Django est livré avec Sqlite, pour l’instant, je vais m’en contenter.

Dans le dossier du projet, il y a un fichier settings.py. C’est ici que se change le driver de la base de données.

On y trouve aussi INSTALLED_APPS, qui enregistre toutes les apps du projet. Je ne sais pas encore pourquoi, mais mon app articles n’est pas dedans pour l’instant. Passons.

Il faut lancer les migrations, parce que toutes les apps de INSTALLED_APPS ont potentiellement besoin d’un petit setup en base. On n’oublie pas de lancer sources bin/activate si on a désactivé l’environnement, et on lance :

python manage.py migrate

#qui retourne :

Operations to perform:
  Apply all migrations: auth, sessions, admin, contenttypes
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying sessions.0001_initial... OK

Toujours pas de traces de l’app articles.

Les modèles et migrations

En allant plus loin, je me rends compte qu’en réalité, les apps ne sont pas liés qu’à 1 seul model. C’est ce que j’avais crus comprendre, mais en fait pas du tout. Une app pourrait s’appeler newsletter par exemple, et contenir le model optin, le model des types de newsletters, et la table pivot par exemple.
C’est un peu déroutant quand on vient de PHP, mais je pense qu’en matière de ré-utilisabilité, et lisibilité, ça aide considérablement.

Dans Django, les migrations sont faites à partir de ce qu’on code dans les différents fichiers models.py : il y a un générateur qui fait le travail. Que ce soit sur Rails ou Laravel, c’est 2 choses séparées. Ce qui m’a valut pas mal de soucis, donc ça doit être une bonne chose également.

J’espère juste que les requêtes, scopes, et données de migrations ne sont pas tous dans un même fichier, parce que comme on l’a vu plus haut : les apps peuvent contenir plusieurs models dans un même fichier models.py.
Ca peut vite être un fichier trop volumineux, mais j’imagine qu’on doit pouvoir faire de l’inclusion de fichier.

Pour reprendre le tuto de base, j’ai créé l’app pools. Dans le fichier models.py, on insère donc :

from django.db import models

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Pour l’instant, construire ces class en injectant models.Model me pose problème.
En réalité, c’est comme ça que Python étend une class si je comprends bien : Donc ce n’est pas de la construction de class en fait ^^.

Modifier le projet pour charger la nouvelle app et lancer les migrations :

On va donc modifier le fichier settings.py pour ajouter l’app polls :

INSTALLED_APPS = [
'polls.apps.PollsConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]

Alors on peut se demander pourquoi polls.apps.PollsConfig et pas polls.apps.polls. En fait la class est générée automatiquement dans projet/polls/apps.py. Et cette class porte le nom PollsConfig.

J’aime cette idée qu’un fichier porte le nom de la class qu’il gère, mais j’ai l’impression qu’on accorde cette importance uniquement dans la communauté PHP.

On peut maintenant lancer

python manage.py makemigrations polls

#retourne
Migrations for 'polls':
  0001_initial.py:
    - Create model Choice
    - Create model Question
    - Add field question to choice

Ce qu’il faut en retenir, c’est que Django se charge de générer les fichiers de migrations. C’est dans ce sens qu’on ne les gère pas comme dans Rails ou Laravel. Quand les fichiers sont créés, on peut lancer la migration (ou les modifier avant la migration) :

python manage.py migrate

#retourne
Operations to perform:
  Apply all migrations: contenttypes, sessions, auth, admin, polls
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK

On va pouvoir commencer à jouer avec la base de données, et apprendre à faire des requêtes, mais ça sera pour le prochain billet !