Opérations de migration¶
Les fichiers de migration sont composés de un ou plusieurs objets Operation qui enregistrent de manière déclarative les opérations à appliquer à la base de données.
Django utilise également ces objets Operation pour recomposer un état historisé de vos modèles et pour calculer les modifications effectuées aux modèles depuis la dernière migration afin de pouvoir écrire automatiquement les migrations ; c’est pourquoi ils sont déclaratifs, ce qui permet à Django de facilement tous les charger en mémoire et de les parcourir sans devoir accéder à la base de données pour trouver à quoi le projet devrait ressembler.
Certains objets Operation plus spécialisés sont destinés à des opérations comme les migrations de données et pour des manipulations manuelles avancées de la base de données. Vous pouvez même écrire vos propres classes Operation si vous le voulez pour englober des modifications que vous effectuez fréquemment.
Si vous avez besoin d’un fichier de migration vide pour y écrire vos propres objets Operation, exécutez python manage.py makemigrations --empty nom_application, mais soyez conscient que l’ajout manuel d’opérations modifiant le schéma peut perturber l’autodétecteur de migrations et provoquer du code incorrect durant les prochaines exécutions de makemigrations.
Toutes les opérations Django de base se trouvent dans le module django.db.migrations.operations.
Pour du contenu d’initiation, consultez le guide thématique des migrations.
Opérations liées au schéma¶
CreateModel¶
-
class
CreateModel(name, fields, options=None, bases=None, managers=None)¶
Crée un nouveau modèle dans l’historique du projet et une table correspondante dans la base de données.
name est le nom du modèle tel qu’il est écrit dans le fichier models.py.
fields est une liste de tuples binaires (nom_champ, instance_champ). L’instance de champ doit être un champ non lié (« unbound ») (donc simplement models.CharField(…), plutôt qu’un champ repris d’un autre modèle).
options est un dictionnaire facultatif de valeurs tirées de la classe Meta du modèle.
bases est une liste facultative d’autres classes dont ce modèle doit hériter ; elle peut contenir aussi bien des objets classes que des chaînes au format "nomapp.NomModele" si vous voulez dépendre d’un autre modèle (vous héritez donc de sa version historique). En cas d’absence, la valeur par défaut hérite du modèle standard models.Model.
managers accepte une liste de tuples binaires (nom_gestionnaire, instance_gestionnaire). Le premier gestionnaire de la liste sera le gestionnaire par daéfut de ce modèle pour les migrations.
DeleteModel¶
-
class
DeleteModel(name)¶
Supprime le modèle de l’historique du projet et ses tables de la base de données.
RenameModel¶
-
class
RenameModel(old_name, new_name)¶
Renomme le modèle d’un ancien nom vers un nouveau nom.
Il peut arriver que vous deviez ajoutez manuellement cette opération si vous modifiez à la fois le nom du modèle et plusieurs de ses champs ; pour l’autodétecteur, il paraîtra que l’ancien modèle a été supprimé et qu’un nouveau modèle a été ajouté avec un nom différent, ce qui fera que la migration créée perdra toutes les données de l’ancienne table.
AlterModelTable¶
-
class
AlterModelTable(name, table)¶
Modifie le nom de la table du modèle (l’option db_table de la classe interne Meta).
AlterUniqueTogether¶
-
class
AlterUniqueTogether(name, unique_together)¶
Modifie l’ensemble de contraintes d’unicité du modèle (l’option unique_together de la classe interne Meta).
AlterIndexTogether¶
-
class
AlterIndexTogether(name, index_together)¶
Modifie l’ensemble d’index personnalisés du modèle (l’option index_together de la classe interne Meta).
AlterOrderWithRespectTo¶
-
class
AlterOrderWithRespectTo(name, order_with_respect_to)¶
Crée ou supprime la colonne _order nécessaire à l’option order_with_respect_to de la classe interne Meta.
AlterModelOptions¶
-
class
AlterModelOptions(name, options)¶
Stocke les modifications de diverses options de modèles (attributs de la classe Meta d’un modèle) comme permissions ou verbose_name. N’affecte pas la base de données, mais fait persister ces modifications à l’usage des instances RunPython. options doit être un dictionnaire faisant correspondre des noms d’options à leurs valeurs.
AlterModelManagers¶
-
class
AlterModelManagers(name, managers)¶
Modifie les gestionnaires disponibles durant les migrations.
AddField¶
-
class
AddField(model_name, name, field, preserve_default=True)¶
Ajoute un champ à un modèle. model_name est le nom du modèle, name est le nom du champ et field est une instance de champ Field non liée (ce que vous placeriez dans une déclaration de champ dans models.py, par exemple models.IntegerField(null=True)).
Le paramètre preserve_default indique si la valeur par défaut du champ est permanente et doit être incluse dans l’état du projet (True) ou si elle n’est que temporaire et juste pour la migration (False), généralement parce que la migration ajoute un champ non nul à une table et qu’elle a besoin d’une valeur par défaut pour remplir les lignes existantes. Cela ne concerne pas le comportement de définition de valeurs par défaut au sein même de la base de données, car Django ne définit jamais de valeurs par défaut pour la base de données et les applique toujours au niveau du code Django de l’ORM.
Avertissement
Sur les bases de données plus anciennes, l’ajout d’un champ avec valeur par défaut peut provoquer une réécriture complète de la table. Cela arrive même pour des champs avec valeur nulle autorisée et peut affecter les performances en baisse. Pour éviter cela, il s’agit de suivre les étapes suivantes.
- Ajoutez le champ avec valeur nulle autorisée sans valeur par défaut et lancez la commande
makemigrations. Cela devrait générer une migration contenant une opérationAddField. - Ajoutez la valeur par défaut à votre champ et lancez la commande
makemigrations. Cela devrait générer une migration contenant une opérationAlterField.
RemoveField¶
-
class
RemoveField(model_name, name)¶
Supprime un champ d’un modèle.
Gardez en tête que lors de l’inversion de l’opération, un nouveau champ est ajouté au modèle. L’opération est réversible (sans prendre en compte la perte de données qui est irréversible) à la condition que le champ puisse valoir null ou qu’il possède une valeur par défaut utilisable pour remplir la colonne recréée. Dans le cas contraire, l’opération est irréversible.
AlterField¶
-
class
AlterField(model_name, name, field, preserve_default=True)¶
Modifie la définition d’un champ, y compris les modifications de son type, des attributs null, unique, db_column ou des autres attributs de champ.
Le paramètre preserve_default indique si la valeur par défaut du champ est permanente et doit être incluse dans l’état du projet (True) ou si elle n’est que temporaire et juste pour la migration (False), généralement parce que la migration modifie un champ nul vers un champ non nul à une table et qu’elle a besoin d’une valeur par défaut pour remplir les lignes existantes. Cela ne concerne pas le comportement de définition de valeurs par défaut au sein même de la base de données, car Django ne définit jamais de valeurs par défaut pour la base de données et les applique toujours au niveau du code Django de l’ORM.
Notez qu’il n’est pas toujours possible d’effectuer toutes les modifications, aussi en fonction de la base de données. Par exemple, il n’est pas possible de transformer un champ de type texte comme models.TextField() en un champ de type numérique comme models.IntegerField() dans la plupart des bases de données.
RenameField¶
-
class
RenameField(model_name, old_name, new_name)