Django迁移加载Fixture后PostgreSQL主键重复IntegrityError问题排查

1. 你的PostgreSQL主键序列未重置的假设是否正确？ #

完全正确！当你通过fixture手动指定id值插入数据时，PostgreSQL的主键序列（serial/bigserial对应的序列对象）并不会自动同步更新。Wagtail在创建新页面时，会依赖这个序列来生成下一个主键值——如果序列的当前值小于你fixture中使用的最大id，就会出现重复键冲突。

比如你遇到的情况：fixture插入了id=3的页面，但序列的当前值还是停留在Wagtail自动生成的最后一个主键（比如2），那么当你尝试添加新页面时，Wagtail会从序列取到3，就会触发duplicate key错误。你执行sqlsequencereset后错误变成id=4重复，说明序列被更新了，但可能你的fixture中还包含了id=4的记录，或者序列更新后的起始值依然小于fixture中的最大id，本质还是序列未和实际数据对齐的问题。

2. 如何在迁移加载fixture后可靠修复该问题？ #

如果一定要在迁移中加载fixture，你需要在加载完成后手动同步主键序列。最可靠的方式是在迁移中添加一个RunSQL操作，直接更新序列的起始值为表中最大id+1：

from django.db import migrations

class Migration(migrations.Migration):
    dependencies = [
        # 填写你的迁移依赖
    ]

    operations = [
        # 先执行加载fixture的操作（比如RunPython调用loaddata）
        migrations.RunPython(load_fixture_function),
        # 同步wagtailcore_page的主键序列
        migrations.RunSQL(
            "SELECT setval(pg_get_serial_sequence('wagtailcore_page', 'id'), MAX(id)) FROM wagtailcore_page;"
        ),
        # 如果你的自定义Page模型有单独的关联表，也需要同步对应的序列
        migrations.RunSQL(
            "SELECT setval(pg_get_serial_sequence('myapp_newspage', 'page_ptr_id'), MAX(page_ptr_id)) FROM myapp_newspage;"
        ),
    ]

另外，你之前执行sqlsequencereset报错，大概率是因为直接复制了包含BEGIN;和COMMIT;的输出内容。sqlsequencereset生成的是完整的事务语句，你可以用以下命令直接执行，避免语法错误：

./manage.py sqlsequencereset wagtailcore myapp | ./manage.py dbshell

3. 使用Python代码创建内容是否更简单可靠？ #

绝对是的！Fixture的最大问题就是和模型强绑定——一旦模型字段变更（比如新增字段、修改字段类型），旧的fixture就会加载失败，需要手动维护，长期来看维护成本很高。

而用Python代码在迁移中创建内容，直接调用Wagtail的页面API，灵活性和稳定性都强很多：

from django.db import migrations

def create_base_site_structure(apps, schema_editor):
    # 迁移中必须通过apps.get_model获取模型，避免直接引用当前模型
    NewsPage = apps.get_model('myapp', 'NewsPage')
    HomePage = apps.get_model('wagtailcore', 'HomePage')

    # 获取首页作为父页面
    home_page = HomePage.objects.first()

    # 创建自定义NewsPage
    news_page = NewsPage(
        title="News",
        slug="news",
        # 填充其他必填字段
    )
    home_page.add_child(instance=news_page)
    news_page.save_revision().publish()

class Migration(migrations.Migration):
    dependencies = [
        # 确保依赖的模型迁移已执行
        ('myapp', '0001_initial'),
        ('wagtailcore', '0053_locale_model'),
    ]

    operations = [
        migrations.RunPython(create_base_site_structure),
    ]

这种方式不需要关心主键序列——Wagtail会自动处理主键生成，序列也会同步更新，完全避免了主键冲突问题，而且模型变更时，你只需要修改迁移中的代码即可，长期维护更省心。

补充与结论 #

正如你后来发现的，直接调用loaddata虽然能正常运行，但fixture的脆弱性会导致后续模型变更时出现问题。最终你转向Python代码实现的选择非常正确，强烈建议不要在Django/Wagtail迁移中加载fixture，尤其是用于填充站点基础结构的场景——用Python代码创建内容才是长期稳定的方案。

内容的提问来源于stack exchange，提问作者khink