Epic Stack项目中SQLite数据库清理的PRAGMA使用技巧

在Epic Stack项目开发过程中，我们遇到了一个关于SQLite数据库清理的有趣技术问题。当数据库中存在外键约束时，原有的清理函数无法正常工作，这引发了对SQLite事务和PRAGMA命令行为的深入探讨。

问题背景

项目中原有的cleanupDb函数设计用于清理测试数据库中的所有表数据，其实现逻辑是：

1. 获取所有非系统表名
2. 在事务中执行：
   • 禁用外键约束
   • 删除所有表数据
   • 重新启用外键约束

这种设计看似合理，但在实际存在外键约束的情况下却无法正常工作。

技术原理分析

问题的根源在于SQLite中PRAGMA命令的特殊行为。PRAGMA命令在SQLite中的执行作用域是当前语句，而不是整个事务。当我们在事务中使用多个$executeRawUnsafe执行PRAGMA命令时，每个命令都是独立的执行上下文，PRAGMA的设置不会延续到后续语句中。

这就导致了：

1. 第一个PRAGMA命令禁用外键约束
2. 但随后的DELETE语句在新的执行上下文中，外键约束又恢复了
3. 因此DELETE操作会触发外键约束检查

解决方案

正确的做法是将PRAGMA命令放在事务之外执行：

// 禁用外键约束（事务外）
await prisma.$executeRawUnsafe(`PRAGMA foreign_keys = OFF`)

// 在事务中执行数据删除
await prisma.$transaction([
  ...tables.map(({ name }) =>
    prisma.$executeRawUnsafe(`DELETE FROM "${name}"`),
])

// 重新启用外键约束（事务外）
await prisma.$executeRawUnsafe(`PRAGMA foreign_keys = ON`)

异常处理考虑

为了确保系统的健壮性，我们还需要考虑异常情况下的处理。理想情况下，应该使用try-catch块确保外键约束总能被重新启用：

try {
  await prisma.$executeRawUnsafe(`PRAGMA foreign_keys = OFF`)
  await prisma.$transaction([
    ...tables.map(({ name }) =>
      prisma.$executeRawUnsafe(`DELETE FROM "${name}"`),
  ])
} finally {
  await prisma.$executeRawUnsafe(`PRAGMA foreign_keys = ON`)
}

这种模式确保了无论事务成功与否，数据库最终都会回到外键约束启用的状态，避免影响后续操作。

总结

这个案例展示了SQLite中PRAGMA命令的特殊行为，以及如何在Prisma中正确处理外键约束。对于数据库操作，理解底层数据库引擎的行为特性至关重要。在Epic Stack项目中采用这种改进后的清理方法，可以确保测试数据库在各种约束条件下都能被正确清理，为测试环境提供了更可靠的保障。