Instatic数据库变更管理：迁移脚本与版本控制完全指南

Instatic数据库变更管理：迁移脚本与版本控制完全指南

【免费下载链接】InstaticInstatic is a modern self-hosted visual CMS - get it running in 1 minute项目地址: https://gitcode.com/GitHub_Trending/in/Instatic

作为一款现代化的自托管可视化CMS，Instatic提供了强大的数据库变更管理机制，让团队协作和版本升级变得简单可靠。无论你是开发者还是系统管理员，掌握Instatic的迁移脚本和版本控制策略都能让你轻松应对数据库结构变化，确保数据安全与系统稳定。

📊 双数据库引擎支持：PostgreSQL与SQLite

Instatic最独特的设计之一是同时支持PostgreSQL和SQLite两种数据库引擎。这意味着你可以：

• 开发环境使用轻量级的SQLite，无需安装额外服务
• 生产环境切换到功能更强大的PostgreSQL，支持多用户并发访问
• 无缝切换只需修改DATABASE_URL配置，代码无需任何改动

这种双引擎架构在server/db/目录中体现得淋漓尽致：

• server/db/client.ts- 统一的数据库客户端接口
• server/db/postgres.ts- PostgreSQL适配器
• server/db/sqlite.ts- SQLite适配器
• server/db/migrations-pg.ts- PostgreSQL迁移脚本
• server/db/migrations-sqlite.ts- SQLite迁移脚本

🔄 迁移脚本：安全升级的保障

Instatic的迁移系统遵循严格的双向同步原则，确保两种数据库引擎的变更完全一致。

迁移脚本结构

每个迁移都有唯一的ID和对应的SQL语句，例如添加AI运行时支持的迁移：

// PostgreSQL版本 { id: '007_ai_runtime', sql: ` create table if not exists ai_provider_credentials ( id text primary key, user_id text not null references users(id) on delete cascade, provider_id text not null, auth_mode text not null, display_label text not null, ciphertext bytea, iv bytea, // ... 更多字段 ) `, } // SQLite版本（对应相同ID） { id: '007_ai_runtime', sql: ` create table if not exists ai_provider_credentials ( id text primary key, user_id text not null references users(id) on delete cascade, provider_id text not null, auth_mode text not null, display_label text not null, ciphertext blob, // bytea → blob iv blob, // ... 更多字段 ) `, }

自动迁移执行

Instatic在启动时会自动检查并执行未应用的迁移：

// server/db/runMigrations.ts export async function runMigrations(db: DbClient, migrations: Migration[]): Promise<void> { await db.unsafe(` create table if not exists schema_migrations ( id text primary key, applied_at text not null default current_timestamp ) `) for (const migration of migrations) { const { rows } = await db<{ id: string }>` select id from schema_migrations where id = ${migration.id} ` if (rows.length > 0) continue // 已应用的跳过 await db.transaction(async (tx) => { await tx.unsafe(migration.sql) // 执行迁移 await tx`insert into schema_migrations (id) values (${migration.id})` }) } }

🛡️ 数据库变更的黄金法则

1. 永远使用增量迁移

Instatic严格遵循只增不减的原则：

• 新增列：使用ALTER TABLE ADD COLUMN
• 新增表：使用CREATE TABLE
• 修改约束：通过重建表实现（SQLite限制）
• 绝不删除：已发布的迁移永不修改或删除

2. JSON列命名规范

所有存储JSON数据的列必须以_json结尾：

-- 正确 ✅ settings_json jsonb not null default '{}' metadata_json text not null default '{}' -- 错误 ❌ settings jsonb not null default '{}' metadata text not null default '{}'

这个约定让数据库适配器能够自动处理JSON序列化与反序列化，无论底层是PostgreSQL的jsonb还是SQLite的text类型。

3. 跨数据库兼容性

Instatic的迁移系统处理了所有数据库差异：

📈 实际迁移案例解析

案例1：添加定时发布功能

当Instatic需要支持定时发布功能时，迁移脚本需要：

1. 在PostgreSQL中添加新列和状态：

-- migrations-pg.ts alter table data_rows add column if not exists scheduled_publish_at timestamptz; alter table data_rows drop constraint if exists data_rows_status_check; alter table data_rows add constraint data_rows_status_check check (status in ('draft', 'published', 'unpublished', 'scheduled'));

2. 在SQLite中重建表（因为SQLite不支持修改CHECK约束）：

-- migrations-sqlite.ts pragma defer_foreign_keys = on; create table data_rows__migr006 ( -- 原有列... scheduled_publish_at text, -- 新增列 constraint data_rows_status_check check (status in ('draft', 'published', 'unpublished', 'scheduled')) ); -- 复制数据、删除旧表、重命名新表...

案例2：添加布局系统

添加新的系统表layouts时，需要扩展data_tables.kind枚举：

-- PostgreSQL：修改CHECK约束 alter table data_tables drop constraint data_tables_kind_check; alter table data_tables add constraint data_tables_kind_check check (kind in ('postType', 'data', 'page', 'component', 'layout')); -- SQLite：重建表（因为涉及RESTRICT外键引用） { id: '017_layouts_system_table', disableForeignKeys: true, // 临时禁用外键检查 sql: ` create table data_tables__migr017 ( -- 表结构... constraint data_tables_kind_check check (kind in ('postType', 'data', 'page', 'component', 'layout')) ); -- 数据迁移逻辑... `, }

🔧 迁移开发最佳实践

1. 创建新迁移的步骤

# 1. 确定下一个迁移ID（按顺序递增） # 当前最新是019，下一个就是020 # 2. 在migrations-pg.ts中添加PostgreSQL版本 { id: '020_your_feature_name', sql: ` -- PostgreSQL特定的DDL语句 create table if not exists new_table ( id text primary key, data_json jsonb not null default '{}' ) `, } # 3. 在migrations-sqlite.ts中添加对应的SQLite版本 { id: '020_your_feature_name', sql: ` -- SQLite特定的DDL语句 create table if not exists new_table ( id text primary key, data_json text not null default '{}' ) `, } # 4. 运行测试确保兼容性 bun test src/__tests__/architecture/migration-parity.test.ts

2. 处理数据库差异

PostgreSQL的优势：

• 支持ALTER TABLE DROP CONSTRAINT
• 支持ADD COLUMN IF NOT EXISTS
• 原生jsonb类型提供JSON查询能力

SQLite的限制：

• 不支持修改CHECK约束
• 不支持删除列
• 需要通过重建表来实现结构变更

Instatic的迁移系统封装了这些差异，开发者只需关注业务逻辑。

3. 数据迁移策略

对于需要修改现有数据的迁移，Instatic采用事务性批量更新：

-- 在事务中执行数据迁移 begin; update users set step_up_auth_mode = 'required' where step_up_auth_mode is null; commit;

🚀 版本控制与协作工作流

1. 迁移追踪表

Instatic使用schema_migrations表追踪已应用的迁移：

create table if not exists schema_migrations ( id text primary key, applied_at text not null default current_timestamp )

每次启动时，系统会检查并执行所有未应用的迁移，确保数据库处于最新状态。

2. 团队协作策略

• 开发环境：每次拉取代码后自动应用新迁移
• 测试环境：在CI/CD流水线中验证迁移
• 生产环境：部署前备份，部署后自动迁移

3. 回滚策略

虽然Instatic不提供自动回滚（遵循"只向前"原则），但提供了完整的备份恢复机制：

• 数据库快照
• 迁移前的数据备份
• 详细的迁移日志

📊 迁移统计与监控

Instatic的迁移系统包含丰富的监控能力：

🎯 核心优势总结

1.零停机升级

迁移在事务中执行，失败自动回滚，确保数据一致性。

2.双向兼容

一套代码，两种数据库，开发生产环境一致。

3.自动版本管理

系统自动追踪迁移状态，无需手动干预。

4.安全第一

所有迁移都是增量的，绝不删除已有数据。

5.团队友好

清晰的迁移历史，便于协作和问题排查。

🔮 未来展望

Instatic的数据库迁移系统将持续演进：

1. 迁移验证工具：在应用前模拟执行，预测潜在问题
2. 数据迁移预览：显示将受影响的数据量
3. 迁移回放：在测试环境重放生产环境的迁移序列
4. 性能优化：大规模数据迁移的批处理和进度指示

无论你是个人开发者还是企业团队，Instatic的数据库变更管理系统都能为你提供可靠、安全、高效的数据库升级体验。通过严格的版本控制和双向兼容设计，确保你的CMS系统能够平稳演进，同时保护珍贵的内容数据。

掌握Instatic的迁移脚本和版本控制，你就掌握了系统长期稳定运行的关键。从简单的字段添加到复杂的表结构重构，Instatic的迁移系统都能为你提供坚实的保障。

【免费下载链接】InstaticInstatic is a modern self-hosted visual CMS - get it running in 1 minute项目地址: https://gitcode.com/GitHub_Trending/in/Instatic