测试中遭遇Django IntegrityError异常：已重命名的old_column列仍触发非空约束报错

这种情况确实挺挠头的——明明数据库里已经看不到旧列了，却还报相关的非空约束错误，我之前也碰到过类似的坑，咱们一步步来拆解：

1. 先排查Django端的缓存与迁移状态 #

• 先确认你的Django模型里已经彻底移除了old_column，并且对应的重命名迁移已经成功执行。运行python manage.py showmigrations，看看目标app的迁移是否都标了[X]（已应用）。
• Django的ORM和开发服务器经常会缓存旧的模型结构，立刻重启你的应用服务器（不管是开发用的runserver还是生产环境的Gunicorn/UWSGI），这一步大概率能解决一半的诡异问题。
• 还可以清理Django的全局缓存：python manage.py clearcache，避免缓存的旧表元数据干扰查询。

2. 检查PostgreSQL里的隐藏引用对象 #

PostgreSQL里有些“隐形”的对象可能还攥着旧列不放，即使列本身已经被重命名：

• 查触发器：运行这条SQL看看表上的触发器有没有引用旧列：

  SELECT tgname, tgdef FROM pg_trigger WHERE tgrelid = 'appname_tablename'::regclass;
  

  如果发现有触发器里还写着old_column，要么修改触发器逻辑，要么先删除再重建。
• 查关联视图：有些视图可能是基于旧表结构创建的，运行这条找出来：

  SELECT table_name FROM information_schema.views 
  WHERE table_schema = 'public' AND view_definition LIKE '%old_column%';
  

• 查自定义约束：看看有没有残留的约束还绑定着旧列：

  SELECT conname, condef FROM pg_constraint WHERE conrelid = 'appname_tablename'::regclass;
  

3. 检查数据库连接与事务状态 #

• 你的应用可能还在使用缓存的旧数据库连接，这些连接里的表结构还是重命名前的版本。可以重启应用的数据库连接池，或者干脆重启PostgreSQL服务（如果允许的话），让新连接获取最新的表结构。
• 确认重命名列的操作已经完全提交：在psql里运行SELECT * FROM pg_stat_activity WHERE query LIKE '%old_column%';，看看有没有未完成的事务挂着。

4. 排查代码里的硬编码坑 #

• 翻一遍你的代码，有没有用raw()查询、extra()方法或者直接写SQL的地方还在引用old_column？模型改了但硬编码的SQL没同步更新是常见的疏漏。
• 检查序列化器、表单类、信号处理器这些地方，有没有漏改的old_column字段。

应急临时修复 #

如果一时找不到根源，可以先救急：

1. 临时把旧列加回去（设为允许为空）：

   ALTER TABLE appname_tablename ADD COLUMN old_column [原数据类型] NULL;
   

2. 等应用恢复正常后，再慢慢排查所有引用旧列的地方，彻底清理干净后，再删除这个临时列。

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