使用 Django 1.7 加载初始数据和数据迁移

更新：请参阅下面的@GwynBleidD 的评论，了解此解决方案可能导致的问题，并参见下面的@Rockallite 的回答，了解对未来模型更改更持久的方法。

假设您在 <yourapp>/fixtures/initial_data.json 中有一个夹具文件

创建空迁移： 在 Django 1.7 中： python manage.py makemigrations --empty 在 Django 1.8+ 中，您可以提供一个名称： python manage.py makemigrations --empty --name load_intial_data 编辑您的迁移文件<您的应用程序>/migrations/0002_auto_xxx.py 2.1。自定义实现，受 Django 的 loaddata 启发（初始答案）： 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): "粗暴地删除这个模型的所有条目......" 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. load_fixture 的一个更简单的解决方案（根据@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) 如果您想使用自定义目录，这很有用。 2.3.最简单的：使用 app_label 调用 loaddata 将自动从 的 fixtures 目录加载fixture： from django.core.management import call_command fixture = 'initial_data' def load_fixture(apps, schema_editor): call_command('loaddata', fixture, app_label ='yourapp') 如果你不指定 app_label，loaddata 将尝试从所有应用程序的fixture 目录（你可能不想要）加载fixture 文件名。运行它 python manage.py migrate

---

精简版

您应该不在数据迁移中直接使用 loaddata 管理命令。

# 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),
    ]

长版

loaddata 利用 django.core.serializers.python.Deserializer，它使用最新的模型来反序列化迁移中的历史数据。那是不正确的行为。

例如，假设有一个使用 loaddata 管理命令从夹具加载数据的数据迁移，并且它已经应用于您的开发环境。

稍后，您决定向相应的模型添加一个新的 required 字段，因此您这样做并针对更新的模型进行新的迁移（并且可能在 { 1} 提示您）。

您运行下一次迁移，一切都很好。

最后，您完成了 Django 应用程序的开发，并将其部署在生产服务器上。现在是时候在生产环境中从头开始运行整个迁移了。

但是，数据迁移失败。这是因为来自 loaddata 命令的反序列化模型（代表当前代码）无法与您添加的新 required 字段的空数据一起保存。原始夹具缺少必要的数据！

但即使您使用新字段所需的数据更新夹具，数据迁移仍然失败。当数据迁移运行时，下一次将相应列添加到数据库的迁移尚未应用。您不能将数据保存到不存在的列中！

结论：在数据迁移中，loaddata 命令会在模型和数据库之间引入潜在的不一致。您绝对应该不在数据迁移中直接使用它。

解决方案

loaddata 命令依赖 django.core.serializers.python._get_model 函数从夹具中获取相应的模型，这将返回模型的最新版本。我们需要对其进行修补，以便获得历史模型。

（以下代码适用于 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),
    ]

---

受到一些评论（即 n__o's）的启发，以及我有很多 initial_data.* 文件分布在多个应用程序中的事实，我决定创建一个 Django 应用程序来促进这些数据迁移的创建。

使用 django-migration-fixture，您可以简单地运行以下管理命令，它将在您的所有 INSTALLED_APPS 中搜索 initial_data.* 文件并将它们转换为数据迁移。

./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.

有关安装/使用说明，请参阅 django-migration-fixture。

---

为了给你的数据库一些初始数据，写一个data migration.在数据迁移中，使用RunPython函数加载你的数据。

不要编写任何 loaddata 命令，因为这种方式已被弃用。

您的数据迁移将只运行一次。迁移是有序的迁移序列。运行 003_xxxx.py 迁移时，django 迁移会在数据库中写入该应用程序已迁移到此（003），并且将仅运行以下迁移。

---

不幸的是，上面介绍的解决方案对我不起作用。我发现每次更改模型时，我都必须更新固定装置。理想情况下，我会改为编写数据迁移以类似地修改创建的数据和夹具加载的数据。

为了方便此 I wrote a quick function，它将在当前应用程序的 fixtures 目录中查找并加载固定装置。将此函数放入与迁移中的字段匹配的模型历史记录点中的迁移中。

---

在我看来，固定装置有点糟糕。如果您的数据库经常更改，那么让它们保持最新将很快成为一场噩梦。实际上，这不仅是我的观点，在“Two Scoops of Django”一书中，它的解释要好得多。

相反，我将编写一个 Python 文件来提供初始设置。如果您需要更多内容，我建议您查看 Factory boy。

如果您需要迁移一些数据，您应该使用 data migrations。

还有关于使用固定装置的"Burn Your Fixtures, Use Model Factories"。

---

在 Django 2.1 上，我想用初始数据加载一些模型（例如国家名称）。

但我希望这在执行初始迁移后立即自动发生。

因此，我认为在需要加载初始数据的每个应用程序中都有一个 sql/ 文件夹会很棒。

然后在那个 sql/ 文件夹中，我将有 .sql 个文件，其中包含将初始数据加载到相应模型中所需的 DML，例如：

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

https://i.stack.imgur.com/YJQ5K.png

我还发现了一些需要以特定顺序执行 sql 脚本的情况。所以我决定在文件名前加上一个连续的数字，如上图所示。

然后我需要一种方法来通过执行 python manage.py migrate 自动加载任何应用程序文件夹中可用的任何 SQLs。

因此，我创建了另一个名为 initial_data_migrations 的应用程序，然后将此应用程序添加到 settings.py 文件中的 INSTALLED_APPS 列表中。然后我在里面创建了一个 migrations 文件夹并添加了一个名为 run_sql_scripts.py 的文件（这实际上是一个自定义迁移）。如下图所示：

https://i.stack.imgur.com/4pjZv.png

我创建了 run_sql_scripts.py，以便它负责运行每个应用程序中可用的所有 sql 脚本。然后当有人运行 python manage.py migrate 时触发这个。此自定义 migration 还将所涉及的应用程序添加为依赖项，这样它仅在所需的应用程序执行其 0001_initial.py 迁移后才尝试运行 sql 语句（我们不想尝试针对不存在的表）。

这是该脚本的来源：

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))
    ]

我希望有人觉得这很有帮助，它对我来说很好用！如果您有任何问题，请告诉我。

注意：这可能不是最好的解决方案，因为我刚刚开始使用 django，但是仍然想与大家分享这个“操作方法”，因为我在谷歌搜索时没有找到太多信息。

---