Il est donc assez facile de se confondre lorsque
vous regardez pour la première fois les modèles de données
, les migrations et la base de données elle-même.
Et donc je veux passer en revue ça un peu plus en détail.
Donc, les makemigrations sont ce qui lit les
fichiers models.py, puis
il crée ce qu'on appelle les migrations.
Et la chose clé est que cela est guidé par
la liste des applications dans settings.py.
Donc, si vous faites une nouvelle chose et que vous faites une nouvelle application,
et que vous modifiez le fichier models et que vous essayez
d'exécuter un makemigrations et qu'il ne voit
rien comme, qu'est-ce qu'il vient de faire ?
Eh bien, avez-vous édité votre settings.py ? Parce qu'il y a
une chose appelée applications installées dans votre settings.py.
Désormais, les migrations sont portables entre les bases de données.
Cela signifie que la migration
est une description logique de ce à quoi
doivent ressembler les tables et qu'elles sont une évolution.
Ce qu'ils signifient est comme la première version
de cette table, à partir du
premier models.py lors de la première exécution des migrations, est 001.
Et puis si vous changez models.py
et que vous exécutez une migration à nouveau,
il regarde les changements de
la migration 001 vers models.py, puis 002,
et puis 002 n'est pas comme effacer tout et recommencer,
c'est comme, « Oh, attendez, vous venez d'ajouter une colonne.
Je vais aller de l'avant et ajouter cette colonne. » Mais ce
n'est pas fait d'une manière qui est SQL réel.
Donc les migrations sont elles-mêmes un
peu comme Python et elles sont portables entre les bases de données, ce
qui signifie que vous pourriez sur
votre ordinateur utiliser SQLite, et en production
, vous pourriez utiliser MySQL, et
les migrations sont les mêmes pour
les deux parce qu'ils disent simplement,
« Voici le , voici les types,
voici ce qu'ils sont censés être. »
Maintenant, contraste avec une commande migrate.
La commande migrate lit
toutes les migrations
, puis sait
à quelle base de données elle parle et exécute les commandes SQL pour créer
les tables nécessaires et/ou faire évoluer les tables nécessaires.
Donc, il semble et dit oh, voici
la première migration, voici la deuxième migration,
voici la troisième migration. Je vais faire la table,
je vais changer la table, je vais changer la table,
je vais changer la table, et à la
fin de toute la migration,
la migration passe ensuite par
toutes les migrations et a ensuite
une table de base de données qui reflète
la somme totale des migrations,
qui reflète également le dernier fichier models.py.
Donc c'est un peu complexe.
Cela a à voir avec la portabilité
des bases de données et le fait que nous voulons séparer
les parties portables
de ceci des parties non portables à cela.
Donc, si vous regardez les makemigrations
et voici des échantillons de dj4e,
mes petits échantillons,
il y a beaucoup de modèles là-dedans.
Et si vous jetez un oeil à tous les models.py,
vous voyez que pour chaque application
dans le projet d'échantillons dj4e,
vous voyez un fichier models.py et c'est un
code Python, c'est classe, livre, blah, blah, blah.
C' est très portable et c'est ainsi que
nous, dans notre code Python, dans notre code Django,
voyons le modèle de base de données.
Et quand vous exécutez le makemigration,
cela produit ces fichiers de migration et
ils sont juste dans autos/migrations/001_initial.py, etc.
Et donc vous voyez certains de ceux que j'ai ici,
il y en a en fait deux.
Donc, il a en quelque sorte fait le premier,
puis j'ai dû changer le fichier models,
puis j'ai relancé les makemigrations et il a enregistré
comment ce modèle a changé de
la première version du
fichier models à la deuxième version.
Vous pouvez les regarder, mais ne les éditez pas,
vous pouvez les archiver dans GitHub, mais ne les éditez pas.
Mais jetez un oeil. C'est une représentation très portable.
Ils ressemblent en quelque sorte au fichier models.py.
Tu n'es pas censé les changer,
tu es censé les générer
avec des makemigrations. Et encore une fois,
ceux-ci peuvent aller dans GitHub.
Maintenant, la migration lit essentiellement
tous ces fichiers de migration et
pas seulement un, mais s'
il y a une séquence de fichiers de migration,
il les applique tous dans l'ordre nécessaire.
Et si la
première et la deuxième migration sont appliquées dans
la base de données mais pas la troisième,
elle le sait et dit, « Vous savez quoi,
je vais juste modifier cette base de données
qui existe déjà, qui est déjà en cours d'exécution,
puis ajouter une colonne ou changer
la largeur d'une colonne ou quoi que ce soit
que vous ayez demandé à être fait en éditant votre models.py. »
Donc, lorsque la migration est terminée,
vous vous retrouvez alors avec tout un tas de tables
dans votre base de données et elles sont toutes basées sur
le nom de l'application et le nom
du modèle dans l'application.
Et donc quelque part ici est bookone_book,
bookone_instance, et bookone_lang.
Ils sont tous assis là.
Et donc ce sont toutes les tables. Et nous avons
jeté un oeil à ces tables avant.
Mais c'est la migration qui va
de toutes les petites migrations réparties dans toutes
les applications de ce projet, puis
met en place une base de données qui a toutes ces choses.
Et je continue de dire que les migrations
sont tout au sujet de l'évolution,
parce que si vous regardez ici,
vous voyez une petite table appelée
django_migrations et ce
que Django fait dans cette table django_migrations se souvient de laquelle de
ces migrations ont déjà été appliquées à
cette base de données afin qu'elle traverse les migrations,
elle dit, « Oh, en voici
une qui n'est pas encore faite dans cette base de données,
donc je dois modifier la base de données juste un peu. »
Il se souvient donc des migrations qui ont été faites.
C' est assez fascinant et
dans ces petites applications,
nous n'avons pas toujours besoin d'être aussi intelligents à ce sujet.
Parfois, ce que vous voulez faire est
juste comme, « Je suis confus,
je vais relancer le makemigrate »,
parce que vous n'êtes pas vraiment en production,
vous le faites vraiment encore et encore,
donc vous pouvez réexécuter le makemigrate.
Et la façon dont vous faites cela est que vous
supprimez simplement le fichier,
vous pouvez supprimer ces fichiers.
Je supprimerais tous ceux qui commencent par zéro.
Si vous allez réexécuter makemigrate,
il suffit de réexécuter makemigrations,
supprimer tous ceux qui commencent par zéro
et c'est dans l'application, les
migrations, puis se débarrasser de tout cela,
puis vous pouvez réexécuter
makemigrations et il
lira votre fichier models.py,
puis il fera toutes
les choses nécessaires pour recréer le fichier de migration.
Bon, maintenant ce n'est pas la base de données,
ce sont les instructions sur la façon de créer la base de données, ok ?
C' est comme ça que vous réexécutez makemigrate.
Vous pouvez exécuter migrer à partir de zéro,
c'est en fait plus facile.
Donc, vous pouvez en quelque sorte effacer
les migrations pour une application et je l'ai fait,
juste effacé le bookone ici,
c'est ce que j'ai fait et recommencé,
mais vous pouvez effacer toutes les migrations et
toute la base de données et tout en
supprimant simplement le fichier dans
ce cas parce que nous exécutez SQLite,
effacez simplement le fichier
rm db.sqlite car après la migration,
c'est là que tout se trouve dans ce fichier.
Alors vous essuyez ça, c'est parti.
Maintenant, vous avez peut-être créé un compte administrateur ou
quelque chose et vous allez effacer cela aussi.
Vous allez effacer les données,
vous allez effacer les tables, tout est parti.
C' est une chose que j'aime à propos de SQLite,
vous supprimez ce fichier et il a littéralement disparu.
Et puis vous réexécutez python3 manage.py
migrer et il lit
toutes les migrations et vous fait une belle,
propre, parfaite base de données vide.
Donc, si vous êtes un peu coincé
et que vous n'avez pas peur de perdre vos données,
ce qui dans la plupart des programmeurs débutants,
il est correct d'effacer votre chose SQLite
et de lancer migrer à nouveau.
Vas-y et essaye-le.
Comme je l'ai dit, si vous avez créé un compte administrateur
, eh bien, vous devez le faire à nouveau,
mais c'est le pire que vous pouvez faire,
au moins dans ces applications de début.
Maintenant que nous avons parlé de la
façon de trouver un modèle de données,
comment l'encoder dans Django models.py,
comment faire des migrations, et comment
migrer des choses et comment en faire une base de données,
maintenant nous allons parler du type de
code Python que vous pouvez
exécuter pour mettre à jour ces modèles dans la base de données.
[ MUSIQUE]