Working on migrations and models

source/part-3-django-concepts/migrations.adoc

@@ -1,6 +1,6 @@
 == Migrations
 
-Dans cette section, nous allons voir comment les migrations fonctionnent. 
+Dans cette section, nous allons voir comment les migrations fonctionnent.
 Dans une première version, elles peuvent sembler un peu magiques, dans la mesure où elles appliquent des modifications au niveau du schéma de données en se basant uniquement sur des modifications effectuées sur le modèle.
 
 Pour repartir de notre exemple ci-dessus, nous avions un modèle reprenant quelques classes, et saupoudrées de propriétés.
@@ -10,11 +10,38 @@ Une migration consiste donc à appliquer un ensemble de modifications, qui exerc
 
 Les migrations (comprendre les "_migrations du schéma de base de données_") sont intimement liées à la représentation d'un contexte fonctionnel. L'ajout d'une nouvelle information, d'un nouveau champ ou d'une nouvelle fonction peut s'accompagner de tables de données à mettre à jour ou de champs à étendre.
 
-Toujours dans une optique de centralisation, les migrations sont directement embarquées au niveau du code. Le développeur s'occupe de créer les migrations en fonction des actions à entreprendre; ces migrations peuvent être retravaillées, _squashées_, ... et feront partie intégrante du processus de mise à jour de l'application. 
+Toujours dans une optique de centralisation, les migrations sont directement embarquées au niveau du code. Le développeur s'occupe de créer les migrations en fonction des actions à entreprendre; ces migrations peuvent être retravaillées, _squashées_, ... et feront partie intégrante du processus de mise à jour de l'application.
 
 A noter que les migrations n'appliqueront de modifications que si le schéma est impacté. Ajouter une propriété `related_name` sur une ForeignKey n'engendrera aucune nouvelle action de migration, puisque ce type d'action ne s'applique que sur l'ORM, et pas directement sur la base de données: au niveau des tables, rien ne change. Seul le code et le modèle sont impactés.
 
 
 https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html[reset migrations].
 
->  En gros, soit on supprime toutes les migrations (en conservant le fichier __init__.py), soit on réinitialise proprement les migrations avec un --fake-initial (sous réserve que toutes les personnes qui utilisent déjà le projet s'y conforment... Ce qui n'est pas gagné.
+>  En gros, soit on supprime toutes les migrations (en conservant le fichier __init__.py), soit on réinitialise proprement les migrations avec un --fake-initial (sous réserve que toutes les personnes qui utilisent déjà le projet s'y conforment... Ce qui n'est pas gagné.
+Pour repartir de notre exemple ci-dessus, nous avions un modèle reprenant quelques classes, saupoudrées de propriétés décrivant nos différents champs. Pour être prise en compte par le moteur de base de données, chaque modification doit être
+
+1. Décrite, grâce à la commande `makemigrations`
+2. Appliquée, avec la commande `migrate`.
+
+=== Description d'une migration
+
+
+=== Application d'une ou plusieurs migrations
+
+
+=== Analyse
+
+Nous allons ci-dessous analyser exactement les modifications appliquées au schéma de la base de données, en fonction des différents cas, et comment ils sont gérés par les pilotes de Django.
+Nous utiliserons https://sqlitebrowser.org/[Sqlite Browser] et la commande `sqldump`, qui nous présentera le schéma tel qu'il sera compris
+
+==== Création de nouveaux champs
+
+
+
+==== Modification d'un champ existant
+
+
+==== Suppression d'un champ existant
+
+
+

source/part-3-django-concepts/models.adoc

@@ -1,12 +1,12 @@
 == Modélisation
 
-On va aborder la modélisation des objets en elle-même, qui s'apparente à la conception de la base de données. 
+On va aborder la modélisation des objets en elle-même, qui s'apparente à la conception de la base de données.
 
-Django utilise un modèle https://fr.wikipedia.org/wiki/Mapping_objet-relationnel[ORM] - c'est-à-dire que chaque objet peut s'apparenter à une table SQL, mais en ajoutant une couche propre au paradigme orienté objet. 
-Il sera ainsi possible de définir facilement des notions d'héritage (tout en restant dans une forme d'héritage simple), la possibilité d'utiliser des propriétés spécifiques, des classes intermédiaires, ... 
+Django utilise un paradigme de type https://fr.wikipedia.org/wiki/Mapping_objet-relationnel[ORM] - c'est-à-dire que chaque type d'objet peut s'apparenter à une table SQL, mais en ajoutant une couche propre au modèle orienté objet.
+Il est ainsi possible de définir facilement des notions d'héritage (tout en restant dans une forme d'héritage simple), la possibilité d'utiliser des propriétés spécifiques, des classes intermédiaires, ...
 
-L'avantage de tout ceci est que tout reste au niveau du code. 
-Si nous revenons sur la méthodologie des douze facteurs, ce point-ci concerne principalement la minimisation de la divergence entre les environnements d'exécution. 
+L'avantage de tout ceci est que tout reste au niveau du code.
+Si l'on revient sur la méthodologie des douze facteurs, ce point concerne principalement la minimisation de la divergence entre les environnements d'exécution.
 Déployer une nouvelle instance de l'application pourra être réalisé directement à partir d'une seule et même commande, dans la mesure où *tout est embarqué au niveau du code*.
 
 Assez de blabla, on démarre !
@@ -22,12 +22,12 @@ Assez de blabla, on démarre !
 . ManyToManyField
 . OneToOneField
 
-Dans les examples ci-dessus, nous avons vu les relations multiples (1-N), représentées par des clés étrangères (**ForeignKey**) d'une classe A vers une classe B. 
+Dans les examples ci-dessus, nous avons vu les relations multiples (1-N), représentées par des clés étrangères (**ForeignKey**) d'une classe A vers une classe B.
 Pour représenter d'autres types de relations, il existe également les champs de type *ManyToManyField*, afin de représenter une relation N-N. Les champs de type *OneToOneField*, pour représenter une relation 1-1.
 
-Dans notre modèle ci-dessus, nous n'avons jusqu'à présent eu besoin que des relations 1-N: 
+Dans notre modèle ci-dessus, nous n'avons jusqu'à présent eu besoin que des relations 1-N:
 
-. La première entre les listes de souhaits et les souhaits; 
+. La première entre les listes de souhaits et les souhaits;
 . La seconde entre les souhaits et les parts.
 
 [source,python]
@@ -103,7 +103,7 @@ Pour sélectionner un objet au pif : `return Category.objects.order_by("?").firs
 Les propriétés de la classe Meta les plus utiles sont les suivates:
 
 * `ordering` pour spécifier un ordre de récupération spécifique.
-* `verbose_name` pour indiquer le nom à utiliser au singulier pour définir votre classe 
+* `verbose_name` pour indiquer le nom à utiliser au singulier pour définir votre classe
 * `verbose_name_plural`, pour le pluriel.
 
 ==== Shell