GRDB.swift 中多阶段数据库迁移的最佳实践

在 iOS 应用开发中，数据库迁移是一个需要谨慎处理的关键环节。GRDB.swift 作为 Swift 生态中优秀的数据库工具库，提供了强大的迁移功能。本文将探讨一个实际开发场景：当应用需要将数据库迁移过程拆分为多个独立阶段时，如何正确检测未执行的迁移。

多阶段迁移的背景

在实际开发中，我们可能会遇到需要将数据库迁移过程分为多个阶段的情况。例如：

1. 初始阶段：创建基础表结构，可能涉及从 CoreData 迁移数据
2. 中间阶段：执行一系列架构变更，直到某个关键点
3. 最终阶段：将数据移动到应用组目录后，处理后续所有迁移

这种分阶段的设计可能源于应用架构的重大调整，如存储位置的变更，或是历史遗留问题。

问题现象

当使用多个独立的 DatabaseMigrator 实例时，调用 hasBeenSuperseded() 方法会出现意外结果。该方法会误报存在未执行的迁移，因为它无法识别其他 migrator 实例已执行的迁移。

解决方案

GRDB.swift 的维护者提供了两种解决思路：

方案一：合并迁移器

最直接的解决方案是将所有迁移集中到一个 DatabaseMigrator 实例中。由于 migrator 是配置对象而非状态对象，我们可以通过继承方式构建：

// 基础迁移器
var baseMigrator = DatabaseMigrator()
baseMigrator.registerMigration("v1") { db in
    // 初始迁移
}

// 中间阶段迁移器
var intermediateMigrator = baseMigrator
intermediateMigrator.registerMigration("v2") { db in
    // 中间迁移
}

// 最终迁移器
var finalMigrator = intermediateMigrator
finalMigrator.registerMigration("v3") { db in
    // 最终迁移
}

这种方式保持了迁移历史的完整性，使 hasBeenSuperseded() 能正确工作。

方案二：自定义检测逻辑

如果无法合并迁移器，可以手动检测未知迁移：

let appliedIdentifiers = try finalMigrator.appliedIdentifiers(db)
let knownIdentifiers = Set(baseMigrator.migrations + 
                         intermediateMigrator.migrations + 
                         finalMigrator.migrations)
let containsUnknownMigration = appliedIdentifiers.contains { !knownIdentifiers.contains($0) }

技术要点

1. 迁移器本质：DatabaseMigrator 是配置对象，不包含状态，可以安全复制和扩展。

2. 迁移检测原理：hasBeenSuperseded() 默认假设未知迁移是新版本添加的，这种设计主要考虑同一应用多版本共存场景。

3. 迁移表设计：GRDB 将所有迁移记录存储在同一个系统表中，这是导致多 migrator 实例检测问题的根本原因。

最佳实践建议

1. 尽量保持单一迁移器实例，通过继承方式扩展迁移步骤。

2. 对于必须分阶段的情况，考虑为每个 DatabaseMigrator 使用独立的迁移记录表（未来版本可能支持此功能）。

3. 重大架构变更（如存储位置迁移）后，建议重新整合迁移逻辑。

4. 在测试阶段充分验证迁移路径，特别是降级场景。

总结

GRDB.swift 提供了灵活的数据库迁移机制，理解其设计理念对于处理复杂迁移场景至关重要。在多阶段迁移场景中，通过合理组织迁移器结构，既能保持代码清晰，又能确保迁移检测的准确性。记住，迁移代码一旦发布就不能修改，因此前期的合理设计尤为重要。