如何解决Django模型中使用Meta类时出现relation does not exist错误

问题产生原因 #

• 核心原因是你在Person模型的Meta类中配置了managed = False：这个配置的作用是告诉Django 不需要为该模型管理数据库表结构，执行makemigrations和migrate时，Django不会自动生成创建、修改person表的SQL，也不会主动创建这个表。
• 触发报错的场景：执行migrate命令就报错，说明Django在运行迁移的前置步骤中就尝试访问了person表，通常是项目启动阶段（加载路由、加载App配置）就执行了查询Person模型的代码，或者其他模型有外键关联到Person，而关联的模型是managed = True，迁移时需要校验外键关联的表存在。
• 额外的模型定义问题：你已经将user字段设为primary_key=True，又单独定义了id字段，会覆盖Django默认的主键逻辑，后续你返回self.id也不会是默认的自增主键值，这个问题也需要同步修正。

修复步骤 #

方案1：需要Django管理person表（绝大多数场景的选择） #

直接删除Person模型Meta类中的managed = False配置即可，后续操作：

1. 清空所有App下migrations目录中除了__init__.py之外的所有文件
2. 重新执行python manage.py makemigrations [你的App名]
3. 执行python manage.py migrate，此时Django会自动创建person表，报错消失。

方案2：确实需要手动维护person表（比如表是其他系统创建的，Django只做读写） #

1. 先手动在PostgreSQL数据库中创建person表，表结构要和你定义的Person模型完全一致，参考SQL：

CREATE TABLE person (
    user_id integer PRIMARY KEY REFERENCES auth_user(id) ON DELETE CASCADE,
    birthday date,
    gender varchar(20) NOT NULL,
    height varchar(3) NOT NULL,
    id varchar(100) NOT NULL,
    weight varchar(3) NOT NULL
);

2. 排查项目中所有在Django启动阶段就执行的Person模型查询代码，把这些查询移到请求处理逻辑、或者异步任务等启动后才执行的位置，避免执行migrate时提前触发表查询。
3. 再执行migrate命令即可正常运行。

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