Yesod+Persistent迁移异常：PostgreSQL中ALTER COLUMN变为DROP COLUMN原因咨询

这问题确实挺闹心的——好好的迁移突然变成要删列，还涉及数据丢失风险，我来帮你梳理几个可能的原因和排查方向：

先明确核心现象 #

之前部署时的迁移语句：

ALTER TABLE "collected_highway" ALTER COLUMN "admin_unit" TYPE varchar(8);
ALTER TABLE "collected_highway" ALTER COLUMN "date" SET DEFAULT Now();

现在突然变为：

ALTER TABLE "collected_highway" ALTER COLUMN "admin_unit" TYPE varchar(8);
ALTER TABLE "collected_highway" DROP COLUMN "date";

本地执行stack exec yesod devel连接同一远程库无此问题，模型长期未修改：

CollectedHighway
    highway Highway
    userId Int64
    highwayId Int64
    adminUnit Text sqltype=varchar(8)
    date UTCTime default=Now()
    UniqueCH userId highway

使用的yesod-bin版本：1.5.2.3

可能的原因及排查步骤 #

1. 部署环境与本地的依赖版本不一致

虽然你确认了yesod-bin的版本，但Persistent的迁移逻辑主要由persistent、persistent-postgresql、yesod-persistent这几个库决定，部署环境和本地的这些包版本差异可能导致迁移逻辑的变化。比如某些旧版本的Persistent在检测列默认值或类型匹配时存在bug，会错误判定列需要删除。

• 排查方式：在部署环境和本地分别执行stack list-dependencies，对比输出中persistent、persistent-postgresql、yesod-persistent的版本，确保完全一致。

2. 数据库连接配置或权限问题

部署环境的数据库连接配置可能和本地有差异，导致Persistent无法正确读取表的元数据：

• 检查部署环境的连接字符串，是否设置了特殊的search_path，导致Persistent找不到目标表所在的schema；
• 确认部署环境使用的数据库用户拥有足够的权限（比如SELECT权限查看information_schema），如果权限不足，Persistent可能无法正确识别date列的存在或属性，从而错误生成DROP语句。

3. Persistent迁移历史表异常

Persistent会在数据库的migrations表中记录已执行的迁移历史，如果这个表的记录丢失、损坏或和本地不一致，Persistent会重新计算需要的迁移操作，可能误判date列为多余列。

• 排查方式：在部署环境的数据库中执行查询：

  SELECT * FROM migrations WHERE name LIKE '%CollectedHighway%';
  

  对比本地数据库的同表记录，看是否有缺失或不匹配的条目。注意操作前先备份该表，不要随意修改。

4. 数据库中date列的实际属性被修改

虽然你说模型没改，但有可能数据库中的date列属性被手动修改过（比如类型、默认值、可空性），导致Persistent无法匹配模型定义，误以为这是一个多余的列：

• 排查方式：执行SQL查询查看列的实际属性：

  SELECT column_name, data_type, is_nullable, column_default 
  FROM information_schema.columns 
  WHERE table_name = 'collected_highway' AND column_name = 'date';
  

  对比模型定义：UTCTime对应PostgreSQL的timestamp with time zone，默认值应为CURRENT_TIMESTAMP（对应Now()）。如果实际属性和模型不符，Persistent可能会判定该列不属于当前模型，从而生成DROP语句。

5. 编译模式差异

本地yesod devel是开发模式编译，部署环境可能使用生产模式编译（比如stack build --production），编译时的flags或配置可能影响Persistent的代码生成逻辑，导致模型解析出现偏差：

• 检查部署环境的stack.yaml或cabal.project文件，确认和本地的配置完全一致，没有额外的编译flags或依赖覆盖。

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