Chargement des données initiales avec Django 1.7 et migrations de données

Je suis récemment passé de Django 1.6 à 1.7, et j'ai commencé à utiliser les migrations (je n'ai jamais utilisé South).

Avant la 1.7, j'avais l'habitude de charger les données initiales avec un fixture/initial_data.jsonfichier, qui était chargé avec la python manage.py syncdbcommande (lors de la création de la base de données).

Maintenant, j'ai commencé à utiliser les migrations, et ce comportement est obsolète:

Si une application utilise des migrations, il n'y a pas de chargement automatique des appareils. Étant donné que des migrations seront nécessaires pour les applications dans Django 2.0, ce comportement est considéré comme obsolète. Si vous souhaitez charger les données initiales d'une application, envisagez de le faire dans une migration de données. ( https://docs.djangoproject.com/en/1.7/howto/initial-data/#automatically-loading-initial-data-fixtures )

La documentation officielle n'a pas d'exemple clair sur la façon de le faire, donc ma question est:

Quelle est la meilleure façon d'importer ces données initiales à l'aide de migrations de données:

1. Écrire du code Python avec plusieurs appels à mymodel.create(...),
2. Utilisez ou écrivez une fonction Django ( comme l'appelloaddata ) pour charger des données à partir d'un fichier de fixture JSON.

Je préfère la deuxième option.

Je ne veux pas utiliser South, car Django semble être capable de le faire nativement maintenant.

Mise à jour : Voir le commentaire de @ GwynBleidD ci-dessous pour les problèmes que cette solution peut causer, et voir la réponse de @ Rockallite ci-dessous pour une approche plus durable pour les futurs changements de modèle.

En supposant que vous ayez un fichier de fixture dans <yourapp>/fixtures/initial_data.json

1. Créez votre migration vide:

   Dans Django 1.7:

   python manage.py makemigrations --empty <yourapp>

   Dans Django 1.8+, vous pouvez fournir un nom:

   python manage.py makemigrations --empty <yourapp> --name load_intial_data

2. Modifier votre fichier de migration <yourapp>/migrations/0002_auto_xxx.py

   2.1. Implémentation personnalisée, inspirée de Django ' loaddata(réponse initiale):

   import os
   from sys import path
   from django.core import serializers
   
   fixture_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), '../fixtures'))
   fixture_filename = 'initial_data.json'
   
   def load_fixture(apps, schema_editor):
       fixture_file = os.path.join(fixture_dir, fixture_filename)
   
       fixture = open(fixture_file, 'rb')
       objects = serializers.deserialize('json', fixture, ignorenonexistent=True)
       for obj in objects:
           obj.save()
       fixture.close()
   
   def unload_fixture(apps, schema_editor):
       "Brutally deleting all entries for this model..."
   
       MyModel = apps.get_model("yourapp", "ModelName")
       MyModel.objects.all().delete()
   
   class Migration(migrations.Migration):  
   
       dependencies = [
           ('yourapp', '0001_initial'),
       ]
   
       operations = [
           migrations.RunPython(load_fixture, reverse_code=unload_fixture),
       ]

   2.2. Une solution plus simple pour load_fixture(selon la suggestion de @ juliocesar):

   from django.core.management import call_command
   
   fixture_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), '../fixtures'))
   fixture_filename = 'initial_data.json'
   
   def load_fixture(apps, schema_editor):
       fixture_file = os.path.join(fixture_dir, fixture_filename)
       call_command('loaddata', fixture_file) 

   Utile si vous souhaitez utiliser un répertoire personnalisé.

   2.3. Simplest: appeler loaddataavec app_labelaccessoires volonté de charge du <yourapp>« s fixturesdir automatiquement:

   from django.core.management import call_command
   
   fixture = 'initial_data'
   
   def load_fixture(apps, schema_editor):
       call_command('loaddata', fixture, app_label='yourapp') 

   Si vous ne spécifiez pas app_label, loaddata essaiera de charger le fixturenom de fichier à partir de tous les répertoires de fixtures des applications (ce que vous ne voulez probablement pas).

3. Exécuter

   python manage.py migrate <yourapp>

Version courte

Vous ne devez PAS utiliser loaddatala commande de gestion directement dans une migration de données.

# Bad example for a data migration
from django.db import migrations
from django.core.management import call_command


def load_fixture(apps, schema_editor):
    # No, it's wrong. DON'T DO THIS!
    call_command('loaddata', 'your_data.json', app_label='yourapp')


class Migration(migrations.Migration):
    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(load_fixture),
    ]

Version longue

loaddatautilise django.core.serializers.python.Deserializerqui utilise les modèles les plus à jour pour désérialiser les données historiques dans une migration. C'est un comportement incorrect.

Par exemple, supposons qu'il existe une migration de données qui utilise loaddatala commande de gestion pour charger les données d'un appareil, et qu'elle est déjà appliquée sur votre environnement de développement.

Plus tard, vous décidez d'ajouter un nouveau champ obligatoire au modèle correspondant, donc vous le faites et effectuez une nouvelle migration par rapport à votre modèle mis à jour (et éventuellement fournissez une valeur unique au nouveau champ lorsque ./manage.py makemigrationsvous y êtes invité).

Vous exécutez la prochaine migration et tout va bien.

Enfin, vous avez terminé de développer votre application Django et vous la déployez sur le serveur de production. Il est maintenant temps pour vous d'exécuter toutes les migrations à partir de zéro sur l'environnement de production.

Cependant, la migration des données échoue . En effet, le modèle désérialisé de la loaddatacommande, qui représente le code actuel, ne peut pas être enregistré avec des données vides pour le nouveau champ obligatoire que vous avez ajouté. L'appareil d'origine ne dispose pas des données nécessaires pour cela!

Mais même si vous mettez à jour l'appareil avec les données requises pour le nouveau champ, la migration des données échoue toujours . Lorsque la migration des données est en cours d'exécution, la prochaine migration qui ajoute la colonne correspondante à la base de données n'est pas encore appliquée. Vous ne pouvez pas enregistrer de données dans une colonne qui n'existe pas!

Conclusion: dans une migration de données, laloaddatacommande introduit une éventuelle incohérence entre le modèle et la base de données. Vous ne devez certainement PAS l' utiliser directement dans une migration de données.

La solution

loaddataLa commande s'appuie sur la django.core.serializers.python._get_modelfonction pour obtenir le modèle correspondant à partir d'un appareil, qui renverra la version la plus à jour d'un modèle. Nous devons le patcher de manière singulière pour qu'il obtienne le modèle historique.

(Le code suivant fonctionne pour Django 1.8.x)

# Good example for a data migration
from django.db import migrations
from django.core.serializers import base, python
from django.core.management import call_command


def load_fixture(apps, schema_editor):
    # Save the old _get_model() function
    old_get_model = python._get_model

    # Define new _get_model() function here, which utilizes the apps argument to
    # get the historical version of a model. This piece of code is directly stolen
    # from django.core.serializers.python._get_model, unchanged. However, here it
    # has a different context, specifically, the apps variable.
    def _get_model(model_identifier):
        try:
            return apps.get_model(model_identifier)
        except (LookupError, TypeError):
            raise base.DeserializationError("Invalid model identifier: '%s'" % model_identifier)

    # Replace the _get_model() function on the module, so loaddata can utilize it.
    python._get_model = _get_model

    try:
        # Call loaddata command
        call_command('loaddata', 'your_data.json', app_label='yourapp')
    finally:
        # Restore old _get_model() function
        python._get_model = old_get_model


class Migration(migrations.Migration):
    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(load_fixture),
    ]

Inspiré par certains des commentaires (à savoir n__o) et le fait que j'ai beaucoup de initial_data.*fichiers répartis sur plusieurs applications, j'ai décidé de créer une application Django qui faciliterait la création de ces migrations de données.

L' utilisation django-migration-appareil vous pouvez simplement exécuter la commande de gestion suivante et il recherche dans tous vos INSTALLED_APPSpour les initial_data.*fichiers et les transformer en migrations de données.

./manage.py create_initial_data_fixtures
Migrations for 'eggs':
  0002_auto_20150107_0817.py:
Migrations for 'sausage':
  Ignoring 'initial_data.yaml' - migration already exists.
Migrations for 'foo':
  Ignoring 'initial_data.yaml' - not migrated.

Voir django-migration-fixture pour les instructions d'installation / d'utilisation.

Afin de donner à votre base de données des données initiales, écrivez une migration de données. Dans la migration de données, utilisez le RunPython fonction pour charger vos données.

N'écrivez aucune commande loaddata car cette méthode est obsolète.

Vos migrations de données ne seront exécutées qu'une seule fois. Les migrations sont une séquence ordonnée de migrations. Lorsque les migrations 003_xxxx.py sont exécutées, les migrations django écrit dans la base de données que cette application est migrée jusqu'à celle-ci (003) et exécutera uniquement les migrations suivantes.

Les solutions présentées ci-dessus n'ont malheureusement pas fonctionné pour moi. J'ai constaté que chaque fois que je change de modèle, je dois mettre à jour mes appareils. Idéalement, j'écrirais plutôt des migrations de données pour modifier les données créées et les données chargées par les appareils de la même manière.

Pour faciliter cela, j'ai écrit une fonction rapide qui cherchera dans le fixturesrépertoire de l'application actuelle et chargera un appareil. Mettez cette fonction dans une migration au point de l'historique du modèle qui correspond aux champs de la migration.

À mon avis, les luminaires sont un peu mauvais. Si votre base de données change fréquemment, les maintenir à jour deviendra bientôt un cauchemar. En fait, ce n'est pas seulement mon avis, dans le livre "Two Scoops of Django" c'est bien mieux expliqué.

Au lieu de cela, j'écrirai un fichier Python pour fournir la configuration initiale. Si vous avez besoin de quelque chose de plus, je vous suggère de regarder Factory boy .

Si vous avez besoin de migrer certaines données, vous devez utiliser des migrations de données .

Il y a aussi "Gravez vos appareils, utilisez des usines de modèles" sur l'utilisation des appareils.

Sur Django 2.1, je voulais charger certains modèles (comme les noms de pays par exemple) avec les données initiales.

Mais je voulais que cela se produise automatiquement juste après l'exécution des migrations initiales.

J'ai donc pensé que ce serait formidable d'avoir un sql/dossier dans chaque application qui nécessitait le chargement des données initiales.

Ensuite, dans ce sql/dossier, j'aurais des .sqlfichiers avec les DML requis pour charger les données initiales dans les modèles correspondants, par exemple:

INSERT INTO appName_modelName(fieldName)
VALUES
    ("country 1"),
    ("country 2"),
    ("country 3"),
    ("country 4");

Pour être plus descriptif, voici à quoi sql/ressemblerait une application contenant un dossier:

J'ai également trouvé des cas où j'avais besoin du sql scripts soient exécutés dans un ordre spécifique. J'ai donc décidé de préfixer les noms de fichiers avec un numéro consécutif comme le montre l'image ci-dessus.

Ensuite, j'avais besoin d'un moyen de charger SQLsautomatiquement tout disponible dans n'importe quel dossier d'application en faisantpython manage.py migrate .

J'ai donc créé une autre application nommée initial_data_migrationspuis j'ai ajouté cette application à la liste des INSTALLED_APPSdans le settings.pyfichier. Ensuite, j'ai créé un migrationsdossier à l'intérieur et ajouté un fichier appelé run_sql_scripts.py( qui est en fait une migration personnalisée ). Comme le montre l'image ci-dessous:

J'ai créé run_sql_scripts.pypour qu'il s'occupe d'exécuter tous les sqlscripts disponibles dans chaque application. Celui-ci est ensuite renvoyé lorsque quelqu'un court python manage.py migrate. Cette coutume migrationajoute également les applications impliquées en tant que dépendances, de cette façon, elle tente d'exécuter les sqlinstructions uniquement après que les applications requises ont exécuté leurs 0001_initial.pymigrations (nous ne voulons pas tenter d'exécuter une instruction SQL sur une table inexistante).

Voici la source de ce script:

import os
import itertools

from django.db import migrations
from YourDjangoProjectName.settings import BASE_DIR, INSTALLED_APPS

SQL_FOLDER = "/sql/"

APP_SQL_FOLDERS = [
    (os.path.join(BASE_DIR, app + SQL_FOLDER), app) for app in INSTALLED_APPS
    if os.path.isdir(os.path.join(BASE_DIR, app + SQL_FOLDER))
]

SQL_FILES = [
    sorted([path + file for file in os.listdir(path) if file.lower().endswith('.sql')])
    for path, app in APP_SQL_FOLDERS
]


def load_file(path):
    with open(path, 'r') as f:
        return f.read()


class Migration(migrations.Migration):

    dependencies = [
        (app, '__first__') for path, app in APP_SQL_FOLDERS
    ]

    operations = [
        migrations.RunSQL(load_file(f)) for f in list(itertools.chain.from_iterable(SQL_FILES))
    ]

J'espère que quelqu'un trouve cela utile, cela a très bien fonctionné pour moi !. Si vous avez des questions, n'hésitez pas à me le faire savoir.

REMARQUE: Ce n'est peut-être pas la meilleure solution puisque je ne fais que commencer avec django, mais je voulais toujours partager ce "Guide pratique" avec vous tous car je n'ai pas trouvé beaucoup d'informations en cherchant sur Google à ce sujet.