drizzle-kit 0.31.7 修复详解：push 到 PostgreSQL 18 时 schema 未变更却生成多余 DROP SQL

后端数据库ORM【免费下载链接】drizzle-ormORM项目地址https://gitcode.com/gh_mirrors/dr/drizzle-orm点击查看免费下载导读本文聚焦 drizzle-kit 0.31.7 发布说明中的唯一一条变更修复了drizzle-kit push在 PostgreSQL 18 上、当 schema 实际未发生任何变更时仍然生成多余 DROP SQL 的 bug对应 issue #4944。文章将结合 drizzle-kit 仓库源码完整拆解push命令从数据库 introspection、schema 快照序列化、快照差异比较到 DROP 语句生成与数据丢失拦截的整条调用链帮助你理解多余 DROP从何而来、为何危险、以及升级到 0.31.7 后如何验证修复是否生效。修复背景0.31.x 系列中的一次针对性 Bugfixdrizzle-kit 0.31.7是 0.31 稳定版本线的后续补丁版本官方变更说明changelogs/drizzle-kit/0.31.7.md内容非常聚焦修复drizzle-kit push在 PostgreSQL 18 下、schema 未发生任何修改时产生不必要unnecessaryDROP SQL 的问题。理解这条修复需要先把它放回版本脉络中。0.31.x 系列此前经历了不少结构性与体验性改进0.31.0Enum DDL 改进删除/重排 enum 值时切换列类型并重建默认表达式、esbuild 升级到 0.25.20.31.1修复使用 Gel extensions含::的 schema 名如ext::auth时pull的问题0.31.2修复关系提取与 Drizzle Studio 相互干扰的问题0.31.3Studio 内部上下文增加databaseName与packageName0.31.4修复halfvec、bit、sparsevec类型生成 bug0.31.6修复 drizzle-kit/api 在 ESM 模块中导入失败的问题。也就是说0.31.7 之前的多个版本都在调整 introspection、类型生成与 Studio 行为而 0.31.7 单独把 PostgreSQL 18 上的 push 误报 DROP 问题拎出来修复说明这是直接影响日常push流程可靠性的一类缺陷。随后 0.31.8 继续修复了algorythm→algorithm拼写与构建外部依赖问题0.31.10 引入tsxloader 并支持原生 Bun/Deno 启动可见 0.31.7 处于 0.31.x 中期把 push 做稳的阶段。drizzle-kit push到 PostgreSQL 的完整工作链路要理解多余 DROP必须先知道push命令在 PostgreSQL 上的执行流水线。仓库中 PostgreSQL push 的入口实现在 drizzle-kit/src/cli/commands/push.ts#L289-L379 的pgPush函数其核心步骤依次为读取数据库当前状态introspection调用pgPushIntrospect见 drizzle-kit/src/introspect-pg.ts连接真实数据库把库中的表、列、索引、约束、enum、policy 等读取为数据库侧快照序列化 Schema 文件调用serializePg(schemaPath, casing, schemasFilter)见 drizzle-kit/src/serializer/index.ts 对应的 pg 序列化实现把 TypeScript schema 文件编译执行后解析成期望侧快照preparePgDbPushSnapshot在 drizzle-kit/src/migrationPreparator.ts#L64-L79 中完成两侧快照与prevId的装配快照差异比较调用preparePgPushdrizzle-kit/src/cli/commands/migrate.ts内部经过applyPgSnapshotsDiffdrizzle-kit/src/snapshotsDiffer.ts逐表、逐列、逐索引比较两个快照产出结构化变更语句JsonStatement数组数据丢失风险评估调用pgSuggestionsdrizzle-kit/src/cli/commands/pgPushUtils.ts#L59-L269对drop_table、alter_table_drop_column、alter_table_alter_column_set_type、drop_schema等危险语句做select count(*)检查非空表/列会打印告警并要求二次确认执行确认通过后逐条执行 SQL。如果第 3 步判定两侧快照完全一致pgPush会走render([i] No changes detected)分支直接结束不会执行任何 SQL见 push.ts#L316-L318。因此一旦出现多余 DROP必然意味着第 1 步或第 3 步出了问题要么 introspection 拿到的数据库快照与真实库不一致要么差异比较逻辑把无差异误判成了有差异。多余 DROP 的生成路径从 diff 到DROP TABLE ... CASCADE当差异比较确实判定某个表被删除时DROP 语句是这样产生的drizzle-kit/src/jsonStatements.ts#L1005-L1012 的prepareDropTableJson生成结构化语句export const prepareDropTableJson (table: Table): JsonDropTableStatement { return { type: drop_table, tableName: table.name, schema: table.schema, policies: table.policies ? Object.values(table.policies) : [], }; };drizzle-kit/src/sqlgenerator.ts#L1517-L1546 的PgDropTableConvertor将其翻译为 SQL同时会先为表上关联的 RLS policy 生成 drop policy 语句最后追加DROP TABLE schema.table CASCADE;注意这里的CASCADE对于被其他表外键引用的表会连带删除依赖。也就是说多余的 DROP不是一句无伤大雅的清理而可能波及真实存在的表结构。在 push 的交互确认环节pgSuggestions会对drop_table语句先执行select count(*) as count from schema.table若行数大于 0则输出类似Youre about to delete table table with count items的告警并把该表加入tablesToRemove同时要求用户在Abort / 继续删除之间选择见 pgPushUtils.ts#L78-L92 与 push.ts#L354-L380。因此 #4944 反映的典型症状是用户在 PostgreSQL 18 上执行drizzle-kit push明明没改 schema终端却弹出要删除某张表的确认甚至直接提示会造成数据丢失迫使用户反复 abort严重干扰开发流程也容易因误操作真正删掉表。为什么 PostgreSQL 18 会触发误判从源码结构推断的可能原因该 changelog 只描述了现象与结论在 PG 18 上、schema 未变更却生成多余 DROP并未公开根因细节。基于仓库代码结构可以作如下谨慎推断差异比较依赖 introspection 结果的稳定可复现pgPushIntrospect的输入是数据库系统表/信息模式查询结果任何由数据库版本引起的元数据表示差异例如信息模式中默认值格式化、类型名表示、约束命名规则的差异都会反映进数据库侧快照快照结构升级逻辑集中在pgUp.tsdrizzle-kit/src/cli/commands/pgUp.ts#L44-L110 中可见 drizzle-kit 的 PostgreSQL 快照 schema 经历过 v5→v6表/枚举键加入 schema 前缀、v6→v7索引列格式从纯字符串改为{ expression, isExpression, asc, nulls, opClass }对象等多次演进。当数据库侧快照由新版本 PostgreSQL 的 introspection 产生、而序列化侧快照仍按旧格式组装时字段级比较就可能产生伪差异类型/表达式表示的方言差异例如timestamp精度表示、numeric默认精度、enum 默认值中::text与::enum的写法差异后者正是 0.31.0 引入的新行为见 changelogs/drizzle-kit/0.31.0.md如果未能在 introspection 侧做等价归一化就会被 diff 视为需要重建列乃至需要重建表。以上属于从源码结构推断层面的分析具体修复点应以其官方发布说明与对应 commit 为准无论如何0.31.7 之后该场景不再产生多余的 DROP SQL。如何在你的环境中复现与验证修复复现前提数据库为 PostgreSQL 18使用与 0.31.6 及更早版本相近的 drizzle-kit0.31.7 修复前的行为执行drizzle-kit push且不修改任何 schema 文件观察是否弹出删除表/列的确认典型触发面项目中存在 enum、带默认值的列、JSON/JSONB 索引或自定义 schema 时更容易命中这些正是 0.31.0~0.31.4 反复调整过的对象类型。验证修复将drizzle-kit升级到0.31.7或更高当前仓库 drizzle-kit/package.json 中版本已迭代至 0.31.11在 schema 零修改的前提下运行drizzle-kit push应稳定输出[i] No changes detected若仍怀疑有差异可配合drizzle-kit push --verbose查看将要执行的完整语句清单对应 push.ts#L331-L340 中statementsToExecute的打印逻辑确认列表为空或仅含预期变更仓库的 push 测试基础设施位于 drizzle-kit/tests/push/pg.test.ts它基于electric-sql/pglite内存实例配合diffTestSchemasPushdrizzle-kit/tests/schemaDiffer.ts直接验证快照差异生成语句的正确性是排查多余 DDL类回归的首选参考。交互确认的防护提醒无论版本如何涉及 DROP 的 push 都存在数据丢失风险。pgSuggestions对以下场景会强制要求确认见 pgPushUtils.tsdrop_table表内行数 0alter_table_drop_column表内行数 0alter_table_alter_column_set_type需要截断表truncate table ... cascadealter_table_add_column新增 not-null 列且无默认值时表内有数据drop_schemaschema 内仍有表。在升级到 0.31.7 之后如果你在未改 schema时仍看到这些确认说明差异检测依然发现了真实差异此时应优先通过--verbose查看具体语句而不是盲目--force跳过确认。小结drizzle-kit 0.31.7修复的核心是 PostgreSQL 18 场景下push的伪差异误判当 introspection 得到的数据库快照与 schema 序列化快照因版本差异未对齐时diff 层会生成多余的DROP TABLE ... CASCADE语句把本应输出No changes detected的正常流程变成高危确认。修复的生效形态是——schema 未变更时push稳定报告无变更、不执行任何破坏性 SQL。对于正在使用 PostgreSQL 18 并频繁push的团队将 drizzle-kit 升至 0.31.7 及以上即可避开该问题如需深入排查或回归验证可围绕 push.ts、pgPushUtils.ts、snapshotsDiffer.ts 与 tests/push/pg.test.ts 展开。赞分享后端数据库ORM【免费下载链接】drizzle-ormORM项目地址https://gitcode.com/gh_mirrors/dr/drizzle-orm点击查看免费下载相关推荐Drizzle Kit 0.31.1全面修复 Gel 扩展 Schema 的 drizzle-kit pull 逆向导入问题Drizzle Kit 0.31.1全面修复 Gel 扩展 Schema 的 drizzle kit pull 逆向导入问题 本篇指南围绕 Drizzle K后端数据库ORMPrettier 变更解析修复 Angular 插值Interpolation中多余空行的生成问题Prettier 变更解析修复 Angular 插值Interpolation中多余空行的生成问题 本篇文章基于 Prettier 仓库中 changel开发工具格式化CLIDrizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移Drizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移 Drizzle Kit 是 Drizzle ORM 官方提供的 CLI后端数据库ORM上一篇革命性权限管理包laravel-permission一站式解决Laravel用户权限难题下一篇自定义SQL函数基于MyBatis-Plus扩展数据库特定函数支持创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考