Working on migrations and models

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

@@ -18,3 +18,30 @@ A noter que les migrations n'appliqueront de modifications que si le schéma est
 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é.
+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

@@ -2,11 +2,11 @@
 
 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. 
+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 !