Kysely 迁移中的数据类型问题解析

Kysely 是一个现代化的 TypeScript SQL 查询构建器，它提供了强大的类型安全特性。然而，在使用 Kysely 进行数据库迁移时，开发者可能会遇到一些类型相关的问题，特别是在需要执行数据转换操作时。

迁移中的数据类型挑战

在 Kysely 的迁移过程中，开发者经常需要在修改表结构的同时对数据进行转换。例如，在添加新列后，可能需要为新列填充数据。这时，开发者会自然地想到使用 Kysely 的 updateTable 方法来更新数据。

然而，迁移环境中的 Kysely 实例与常规应用代码中的实例有所不同。迁移代码必须保持长期稳定，而应用的类型定义会随着项目发展而变化。这种差异导致了类型系统的特殊处理。

问题表现

在迁移代码中，当使用 updateTable 方法时，表达式构建器（ExpressionBuilder）会被类型化为 any，而不是预期的 ExpressionBuilder<any>。这使得开发者失去了类型提示和检查的能力。

await db
  .updateTable('emails')
  .set(eb => ({  // eb 被推断为 any 类型
    id: eb.ref('emails.id')
  }))

解决方案

Kysely 团队确认这是一个需要修复的问题。在 0.27.2 版本中，这个问题已经得到解决。在此之前，开发者可以使用以下临时解决方案：

import { expressionBuilder } from 'kysely'

const eb = expressionBuilder<any, string>()
await db
  .updateTable('emails')
  .set({
    id: eb.ref('emails.id')
  })
  .where('id', 'is', null)  // 注意使用 null 而不是 'NULL'

设计考量

Kysely 在迁移中故意使用无类型查询构建器，这是有充分理由的：

1. 长期稳定性：迁移代码一旦部署就不能更改，而应用类型会不断演进
2. 向后兼容：当表结构发生变化（如列名修改）时，迁移代码仍能正常运行
3. 执行可靠性：避免类型变化导致历史迁移失败

最佳实践

1. 对于简单的数据转换，优先使用原始 SQL 语句
2. 对于复杂逻辑，考虑将数据迁移拆分为单独的步骤
3. 保持迁移代码简单直接，避免依赖应用类型
4. 在必要时使用显式类型断言

总结

Kysely 在迁移环境中的类型处理体现了框架在类型安全和执行可靠性之间的平衡。理解这一设计理念有助于开发者编写更健壮的迁移代码。随着框架的更新，这类边界情况下的开发者体验也在不断改善。