数据库迁移
我们使用
migrate.ps1
PowerShell 脚本将迁移应用到本地开发数据库。此脚本可以处理我们支持的不同数据库提供程序。任何数据库的更改都必须编写为我们的主 DBMS - MSSQL 以及实体框架的迁移脚本。针对每个提供商,请按照以下说明进行操作。
- 1.向后兼容的过渡迁移
- 2.非向后兼容的最终迁移
更改可能无需非向后兼容的结束阶段(即所有更改的最终形式可能是向后兼容的)。在这种情况下,只需要进行一个阶段的更改即可。
- 1.修改
src/Sql/dbo
中的源.sql
文件。 - 2.编写迁移脚本,并将其放在
util/Migrator/DbScripts
中。每个脚本必须以当前日期为前缀。
- 1.将相关的
.sql
文件从src/Sql/dbo
复制到src/Sql/dbo_finalization
。 - 2.移除不再需要的 向后兼容性。
- 3.编写一个新的 Migration 并将其放置在
src/Migrator/DbScripts_finalization
中。将其命名为YYYY-0M-FinalizationMigration.sql
。- 通常,迁移被设计为按顺序运行。但是,由于 DbScripts_future 中的迁移可能会无序运行,因此必须小心确保它们与 DbScripts 的更改保持兼容。为了实现这一目标,我们只保留一个迁移,它执行所有向后不兼容的架构更改。
如果更改数据库架构,则必须创建 EF 迁移脚本以确保 EF 数据库跟上这些更改。开发人员必须这样做,并将迁移包含在他们的 PR 中。
要创建这些脚本,您必须首先根据需要更新
Core/Entities
中的数据模型。这将用于为我们的每个 EF 目标生成迁移。模型更新后,导航到
server
存储库中的 dev
目录并执行 ef_migrate.ps1
PowerShell 命令。您应该提供迁移的名称,将其作为唯一的参数:pwsh ef_migrate.ps1 [NAME_OF_MIGRATION]
这将生成迁移,然后应将其包含在您的 PR 中。
可能需要在正常更新过程之外运行迁移。这些类型的迁移应该出于非常特殊的目的而保留。其中一个原因可能是索引重建。
- 1.编写一个带有当前日期前缀的新迁移并将其放置在
src/Migrator/DbScripts_manual
中 - 2.在我们的云环境中运行它并且我们对结果感到满意后,创建一个 PR 将其移动到
DbScripts
。这将使其能够由我们的迁移器进程在全新安装的云和自托管环境,以及自托管中运行
最近更新 5d ago