32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# 第一阶段数据库迁移
|
||
|
||
本阶段将公司组织、业务伙伴、仓库/库位、物料基础配置和库存余额拆分到独立表。旧的
|
||
`materials.current_stock` 与 `materials.warning_stock` 暂时保留用于回滚观察，但应用代码不再读写。
|
||
|
||
## 执行顺序
|
||
|
||
1. 备份现有数据库，并暂停入库、出库和物料申请操作。
|
||
2. 为当前 shell 设置 `DB_DSN`，不要把账号密码写入仓库。
|
||
3. 在项目根目录运行：
|
||
|
||
```powershell
|
||
go run ./cmd/migrate
|
||
```
|
||
|
||
4. 确认迁移 `001` 到 `006` 均为非 dirty 状态，并检查 `006` 最后的库存差异查询没有结果。
|
||
5. 发布后端和前端，再恢复库存操作。
|
||
|
||
迁移器按文件名顺序执行并记录在 `schema_migrations`。MySQL DDL 可能隐式提交；如果某个版本为
|
||
dirty，迁移器会停止，必须根据报错的语句编号人工核对并修复，不能直接假定事务已回滚。
|
||
|
||
## 核对重点
|
||
|
||
- 每个旧用户均已分配默认组织和默认仓库。
|
||
- 旧物料数量与 `inventory_balances.on_hand` 汇总一致。
|
||
- 旧预警值与 `stock_warning_rules.minimum_available` 一致。
|
||
- `materials` API 响应不再包含库存数量和预警值。
|
||
- 公司组织位于 `organizations`，外部公司位于 `business_partners`，合作关系位于 `organization_partners`。
|
||
|
||
不要在生产库直接试跑。应先在数据库副本验证一次；当前自动化测试只验证迁移执行器和应用查询，
|
||
不替代生产数据副本的迁移核对。
|