后端前端【免费下载链接】react-starter-kitModern React starter kit with Bun, TypeScript, Tailwind CSS, tRPC, Stripe, and Cloudflare Workers. Production-ready monorepo for building fast web apps.项目地址https://gitcode.com/gh_mirrors/rea/react-starter-kit点击查看免费下载导读本文围绕 react-starter-kit 的 数据库迁移文档 展开系统讲解该仓库基于 Drizzle Kit 的迁移工作流如何从 TypeScript schema 自动 diff 生成 SQL 迁移文件、如何区分db:migrate与db:push的使用场景、如何通过:staging/:production后缀安全地定向远端数据库以及如何用db:check校验合并分支后的迁移历史冲突。读完本文你将掌握一套可复现、可审查、多环境隔离的 PostgreSQL 迁移管理方案并理解其底层在db/drizzle.config.ts、db/package.json与迁移目录结构中的实现依据。迁移机制概述schema diff 驱动的 SQL 生成react-starter-kit 使用 Drizzle ORM。其迁移方案的核心思想是以 TypeScript schema 为单一事实来源Drizzle Kit 将当前db/schema/下的表定义与最新的迁移快照snapshot做 diff凡是 schema 与快照不一致的部分都会被转换为增量 SQL写入新的迁移文件。迁移文件的组织方式如下db/ ├── schema/ # 表定义与 relationsuser、organization、subscription 等按域分文件 ├── migrations/ # 自动生成的编号 SQL 迁移文件 │ └── meta/ # 迁移 journal 与 snapshot ├── seeds/ # 种子数据脚本如测试账号 ├── scripts/ # DB 工具脚本seed 运行器、export ├── drizzle.config.ts # Drizzle Kit 配置 ├── index.ts # 重新导出 schema 与 DatabaseSchema 类型 └── package.json # 数据库专属脚本与依赖迁移文件本身是编号的 SQL 文件如0001_add_product_table.sql同时目录下的 journal 负责记录已应用版本。以仓库当前状态为例db/migrations/meta/_journal.json 记录了一条初始条目{ version: 7, dialect: postgresql, entries: [ { idx: 0, version: 1, when: 1751197781613, tag: 0000_init, breakpoints: true } ] }对应的 db/migrations/0000_init.sql 展示了生成产物的典型形态CREATE TABLE语句之间以-- statement-breakpoint分隔接着是ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY外键声明、CREATE INDEX索引定义每条 DDL 都是一个可独立执行、可回滚的断点。这也是评审生成 SQL 时最需要关注的结构。迁移工作流五步标准流程原文档给出的完整工作流如下每一步都可直接照做1. 编辑 schema位置在db/schema/。schema 按实体域拆分为多个文件例如db/schema/user.tsuser、session、identity、verification、db/schema/organization.tsorganization、member、db/schema/invitation.ts、db/schema/subscription.ts、db/schema/passkey.ts全部经 db/schema/index.ts 的 barrel 导出聚合。2. 生成迁移bun db:generate该命令会产出编号 SQL 文件例如0001_add_product_table.sql到db/migrations/。底层实现是 db/package.json 中的generate: bun --bun drizzle-kit generate根目录的db:generate再通过bun --cwd db generate转发过去见 package.json。注意generate是纯本地操作只读 schema 与既有迁移文件从不连接数据库因此它没有:staging/:production变体。3. 评审生成的 SQL。Drizzle Kit 的输出通常正确但必须检查是否存在破坏性操作——列删除、类型变更或数据丢失。迁移文件写盘后要先读一遍再执行db:migrate。4. 应用迁移bun db:migrate5. 在 Drizzle Studio 中验证bun db:studio启动浏览器 UI 检查表结构与数据是否符合预期。Push 与 Migrate 的取舍原文档用一张表明确了三个命令的定位差异这是日常开发中最容易混淆的部分命令作用使用时机bun db:migrate将待应用的迁移应用到本地库本地与共享开发bun db:migrate:env将待应用的迁移应用到指定环境库预发staging与生产productionbun db:push直接同步 schema不生成迁移文件本地开发、快速原型为什么push更快它跳过迁移文件生成环节直接把 schema 状态推到数据库而migrate走的是「生成文件 → 评审 → 按 journal 顺序执行」的可复现路径。原文档的建议非常明确开发期用push提速一旦需要可复现、可评审的变更就切换到migrate。仓库在实现上把这种约束也落到了脚本设计里db/package.json 中push只有drizzle-kit push一个形态没有push:staging/push:production变体。因为push不产迁移文件、不可审计只适合本地原型绝不应用于远端环境。同理db:generate也无远端变体——它根本不触碰数据库。多环境定向:staging与:production后缀原文档指出追加环境后缀即可针对其他数据库执行命令bun db:migrate:staging bun db:migrate:production这些命令的内部行为可以概括为三点设置ENVIRONMENT环境变量、只加载匹配的.env.{env}.local文件、文件缺失时直接失败而不是回退到本地 URL并且该文件中的DATABASE_URL会覆盖 shell 中已导出的同名变量。这一「fail-closed」设计的底层依据在 db/drizzle.config.ts 中可以看到完整实现值得展开环境解析优先读取ENVIRONMENT若等于development会归一为dev如果取值不在[dev, test, staging, production]白名单内直接抛错防止拼写错误悄悄回落到开发环境。无ENVIRONMENT时依次映射NODE_ENV的production/staging/test默认dev。远端环境 fail-closed当解析结果是staging或production时只调用configDotenv加载.env.{env}.local且override: true。文件缺失即抛错“Missing .env.{env}.local – refusing to target {env}”文件存在但没定义DATABASE_URL同样抛错——拒绝复用 shell 或其它工具继承来的连接串。这样环境命名命令永远不会悄悄指向另一个环境的数据库。开发环境级联非远端环境按.env.{env}.local→.env.local→.env顺序加载且首个值生效与 Vite 约定一致显式导出的 shell 变量优先于文件。连接串校验DATABASE_URL必须匹配postgres://或postgresql://前缀正则否则直接报错。配置中的out: ./migrations、schema: ./schema、dialect: postgresql、casing: snake_case则分别对应迁移输出目录、schema 入口、数据库方言与命名映射camelCase 属性自动转 snake_case 列名。另外哪些命令拥有远端变体同样由脚本显式控制package.json、db/package.json命令远端变体原因db:migrate、db:studio、db:export:staging、:production应用迁移、检查数据、备份备份都是真实的远端操作db:seed仅:staging种子脚本创建测试账号不应进入生产db:generate无只读 schema 与既有迁移从不连库db:push无跳过迁移文件仅限本地原型绝不部署迁移历史检查合并分支后的冲突发现当多个分支各自生成了迁移并合并到一起时需要检查生成的迁移历史是否存在冲突bun db:check原文档特别澄清了它的能力边界db:check检查的是生成的迁移历史journal 条目是否出现分叉/冲突不会连接线上数据库也无法检测线上库的 schema 漂移。对于绕过迁移流程的库外变更out-of-band changes正确做法是使用drizzle-kit introspect脚本introspectdb/package.json反查真实库状态然后有意识地写一个调解迁移reconciliation migration来收敛差异。这个区分很重要迁移历史的「线性可复现」与线上库的「实际状态」是两回事前者靠db:check保证后者要靠 introspection 人工评审的调解迁移兜底。实践建议原文档结尾给出了四条高价值实践规则配合源码可以理解得更透为迁移命名bun db:generate --name add-product-table会产出0001_add-product-table.sql这样的清晰文件名而不是纯编号。迁移文件名直接进入 journal 与代码评审视野有语义的名字极大降低追溯成本。一次迁移只做一件事避免把无关的 schema 变更捆在一起。小迁移更易评审、更易回滚——这一点在评审-- statement-breakpoint断点结构时体会最深。绝不修改已应用的迁移一旦迁移已在 staging / production 跑过就把它当作不可变事实。修正问题要新建迁移而不是回改历史文件否则 journal 记录的版本链会与实际库状态脱节。应用前必须评审db:generate只是把 SQL 写到磁盘跑db:migrate之前务必读一遍文件重点排查列删除、类型变更这类破坏性 DDL。完整实操示例给现有库加一张表综合以上内容一个完整的「加表」流程如下可对照 docs/database/schema.md 的「Adding a New Table」章节第一步在db/schema/新建表定义文件以 product 为例使用 prefixed CUID2 主键、timestamp with time zone时间戳、cascade 外键与显式索引// db/schema/product.ts export const product pgTable( product, { id: text() .primaryKey() .$defaultFn(() generateId(prd)), name: text().notNull(), organizationId: text() .notNull() .references(() organization.id, { onDelete: cascade }), createdAt: timestamp({ withTimezone: true, mode: date }) .defaultNow() .notNull(), updatedAt: timestamp({ withTimezone: true, mode: date }) .defaultNow() .$onUpdate(() new Date()) .notNull(), }, (table) [index(product_organization_id_idx).on(table.organizationId)], );第二步在 barrel 文件 db/schema/index.ts 中导出export * from ./product;。第三步生成并评审迁移bun db:generate --name add-product-table # 阅读 db/migrations/0001_add-product-table.sql确认无破坏性 DDL第四步应用并验证bun db:migrate # 本地 bun db:studio # 浏览器中核对 bun db:migrate:staging # 评审通过后推向预发 bun db:migrate:production第五步合并分支后运行bun db:check确认迁移历史无冲突。这套流程覆盖了从 schema 编辑、SQL 生成、人工评审、本地应用到多环境部署的完整闭环也是 docs/database/migrations.md 与 db/README.md 反复强调的「Typical Workflow」的完整落地形态。若想进一步了解 schema 约定prefixed ID、snake_case映射、auth 表扩展方式可继续阅读 docs/database/schema.md环境变量与.env.{env}.local的完整语义见 docs/getting-started/environment-variables.md。赞分享后端前端【免费下载链接】react-starter-kitModern React starter kit with Bun, TypeScript, Tailwind CSS, tRPC, Stripe, and Cloudflare Workers. Production-ready monorepo for building fast web apps.项目地址https://gitcode.com/gh_mirrors/rea/react-starter-kit点击查看免费下载相关推荐Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进与迁移工作流Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进与迁移工作流 本指南以 Karakeep原 hoarder仓库中的官方后端前端移动开发AI 应用知识管理全文检索MCP 服务Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进、迁移生成与 Drizzle Studio 操作指南Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进、迁移生成与 Drizzle Studio 操作指南 本篇技术指南聚焦当前后端前端移动开发AI 应用知识管理全文检索MCP 服务Drizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移Drizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移 Drizzle Kit 是 Drizzle ORM 官方提供的 CLI后端数据库ORM上一篇终极指南如何用 Debugbar 快速优化 Ruby on Rails 应用性能下一篇如何快速上手Practical-Deep-Learning-for-Coders-2.07个计算机视觉实战项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端前端【免费下载链接】react-starter-kitModern React starter kit with Bun, TypeScript, Tailwind CSS, tRPC, Stripe, and Cloudflare Workers. Production-ready monorepo for building fast web apps.项目地址https://gitcode.com/gh_mirrors/rea/react-starter-kit点击查看免费下载导读本文围绕 react-starter-kit 的 数据库迁移文档 展开系统讲解该仓库基于 Drizzle Kit 的迁移工作流如何从 TypeScript schema 自动 diff 生成 SQL 迁移文件、如何区分db:migrate与db:push的使用场景、如何通过:staging/:production后缀安全地定向远端数据库以及如何用db:check校验合并分支后的迁移历史冲突。读完本文你将掌握一套可复现、可审查、多环境隔离的 PostgreSQL 迁移管理方案并理解其底层在db/drizzle.config.ts、db/package.json与迁移目录结构中的实现依据。迁移机制概述schema diff 驱动的 SQL 生成react-starter-kit 使用 Drizzle ORM。其迁移方案的核心思想是以 TypeScript schema 为单一事实来源Drizzle Kit 将当前db/schema/下的表定义与最新的迁移快照snapshot做 diff凡是 schema 与快照不一致的部分都会被转换为增量 SQL写入新的迁移文件。迁移文件的组织方式如下db/ ├── schema/ # 表定义与 relationsuser、organization、subscription 等按域分文件 ├── migrations/ # 自动生成的编号 SQL 迁移文件 │ └── meta/ # 迁移 journal 与 snapshot ├── seeds/ # 种子数据脚本如测试账号 ├── scripts/ # DB 工具脚本seed 运行器、export ├── drizzle.config.ts # Drizzle Kit 配置 ├── index.ts # 重新导出 schema 与 DatabaseSchema 类型 └── package.json # 数据库专属脚本与依赖迁移文件本身是编号的 SQL 文件如0001_add_product_table.sql同时目录下的 journal 负责记录已应用版本。以仓库当前状态为例db/migrations/meta/_journal.json 记录了一条初始条目{ version: 7, dialect: postgresql, entries: [ { idx: 0, version: 1, when: 1751197781613, tag: 0000_init, breakpoints: true } ] }对应的 db/migrations/0000_init.sql 展示了生成产物的典型形态CREATE TABLE语句之间以-- statement-breakpoint分隔接着是ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY外键声明、CREATE INDEX索引定义每条 DDL 都是一个可独立执行、可回滚的断点。这也是评审生成 SQL 时最需要关注的结构。迁移工作流五步标准流程原文档给出的完整工作流如下每一步都可直接照做1. 编辑 schema位置在db/schema/。schema 按实体域拆分为多个文件例如db/schema/user.tsuser、session、identity、verification、db/schema/organization.tsorganization、member、db/schema/invitation.ts、db/schema/subscription.ts、db/schema/passkey.ts全部经 db/schema/index.ts 的 barrel 导出聚合。2. 生成迁移bun db:generate该命令会产出编号 SQL 文件例如0001_add_product_table.sql到db/migrations/。底层实现是 db/package.json 中的generate: bun --bun drizzle-kit generate根目录的db:generate再通过bun --cwd db generate转发过去见 package.json。注意generate是纯本地操作只读 schema 与既有迁移文件从不连接数据库因此它没有:staging/:production变体。3. 评审生成的 SQL。Drizzle Kit 的输出通常正确但必须检查是否存在破坏性操作——列删除、类型变更或数据丢失。迁移文件写盘后要先读一遍再执行db:migrate。4. 应用迁移bun db:migrate5. 在 Drizzle Studio 中验证bun db:studio启动浏览器 UI 检查表结构与数据是否符合预期。Push 与 Migrate 的取舍原文档用一张表明确了三个命令的定位差异这是日常开发中最容易混淆的部分命令作用使用时机bun db:migrate将待应用的迁移应用到本地库本地与共享开发bun db:migrate:env将待应用的迁移应用到指定环境库预发staging与生产productionbun db:push直接同步 schema不生成迁移文件本地开发、快速原型为什么push更快它跳过迁移文件生成环节直接把 schema 状态推到数据库而migrate走的是「生成文件 → 评审 → 按 journal 顺序执行」的可复现路径。原文档的建议非常明确开发期用push提速一旦需要可复现、可评审的变更就切换到migrate。仓库在实现上把这种约束也落到了脚本设计里db/package.json 中push只有drizzle-kit push一个形态没有push:staging/push:production变体。因为push不产迁移文件、不可审计只适合本地原型绝不应用于远端环境。同理db:generate也无远端变体——它根本不触碰数据库。多环境定向:staging与:production后缀原文档指出追加环境后缀即可针对其他数据库执行命令bun db:migrate:staging bun db:migrate:production这些命令的内部行为可以概括为三点设置ENVIRONMENT环境变量、只加载匹配的.env.{env}.local文件、文件缺失时直接失败而不是回退到本地 URL并且该文件中的DATABASE_URL会覆盖 shell 中已导出的同名变量。这一「fail-closed」设计的底层依据在 db/drizzle.config.ts 中可以看到完整实现值得展开环境解析优先读取ENVIRONMENT若等于development会归一为dev如果取值不在[dev, test, staging, production]白名单内直接抛错防止拼写错误悄悄回落到开发环境。无ENVIRONMENT时依次映射NODE_ENV的production/staging/test默认dev。远端环境 fail-closed当解析结果是staging或production时只调用configDotenv加载.env.{env}.local且override: true。文件缺失即抛错“Missing .env.{env}.local – refusing to target {env}”文件存在但没定义DATABASE_URL同样抛错——拒绝复用 shell 或其它工具继承来的连接串。这样环境命名命令永远不会悄悄指向另一个环境的数据库。开发环境级联非远端环境按.env.{env}.local→.env.local→.env顺序加载且首个值生效与 Vite 约定一致显式导出的 shell 变量优先于文件。连接串校验DATABASE_URL必须匹配postgres://或postgresql://前缀正则否则直接报错。配置中的out: ./migrations、schema: ./schema、dialect: postgresql、casing: snake_case则分别对应迁移输出目录、schema 入口、数据库方言与命名映射camelCase 属性自动转 snake_case 列名。另外哪些命令拥有远端变体同样由脚本显式控制package.json、db/package.json命令远端变体原因db:migrate、db:studio、db:export:staging、:production应用迁移、检查数据、备份备份都是真实的远端操作db:seed仅:staging种子脚本创建测试账号不应进入生产db:generate无只读 schema 与既有迁移从不连库db:push无跳过迁移文件仅限本地原型绝不部署迁移历史检查合并分支后的冲突发现当多个分支各自生成了迁移并合并到一起时需要检查生成的迁移历史是否存在冲突bun db:check原文档特别澄清了它的能力边界db:check检查的是生成的迁移历史journal 条目是否出现分叉/冲突不会连接线上数据库也无法检测线上库的 schema 漂移。对于绕过迁移流程的库外变更out-of-band changes正确做法是使用drizzle-kit introspect脚本introspectdb/package.json反查真实库状态然后有意识地写一个调解迁移reconciliation migration来收敛差异。这个区分很重要迁移历史的「线性可复现」与线上库的「实际状态」是两回事前者靠db:check保证后者要靠 introspection 人工评审的调解迁移兜底。实践建议原文档结尾给出了四条高价值实践规则配合源码可以理解得更透为迁移命名bun db:generate --name add-product-table会产出0001_add-product-table.sql这样的清晰文件名而不是纯编号。迁移文件名直接进入 journal 与代码评审视野有语义的名字极大降低追溯成本。一次迁移只做一件事避免把无关的 schema 变更捆在一起。小迁移更易评审、更易回滚——这一点在评审-- statement-breakpoint断点结构时体会最深。绝不修改已应用的迁移一旦迁移已在 staging / production 跑过就把它当作不可变事实。修正问题要新建迁移而不是回改历史文件否则 journal 记录的版本链会与实际库状态脱节。应用前必须评审db:generate只是把 SQL 写到磁盘跑db:migrate之前务必读一遍文件重点排查列删除、类型变更这类破坏性 DDL。完整实操示例给现有库加一张表综合以上内容一个完整的「加表」流程如下可对照 docs/database/schema.md 的「Adding a New Table」章节第一步在db/schema/新建表定义文件以 product 为例使用 prefixed CUID2 主键、timestamp with time zone时间戳、cascade 外键与显式索引// db/schema/product.ts export const product pgTable( product, { id: text() .primaryKey() .$defaultFn(() generateId(prd)), name: text().notNull(), organizationId: text() .notNull() .references(() organization.id, { onDelete: cascade }), createdAt: timestamp({ withTimezone: true, mode: date }) .defaultNow() .notNull(), updatedAt: timestamp({ withTimezone: true, mode: date }) .defaultNow() .$onUpdate(() new Date()) .notNull(), }, (table) [index(product_organization_id_idx).on(table.organizationId)], );第二步在 barrel 文件 db/schema/index.ts 中导出export * from ./product;。第三步生成并评审迁移bun db:generate --name add-product-table # 阅读 db/migrations/0001_add-product-table.sql确认无破坏性 DDL第四步应用并验证bun db:migrate # 本地 bun db:studio # 浏览器中核对 bun db:migrate:staging # 评审通过后推向预发 bun db:migrate:production第五步合并分支后运行bun db:check确认迁移历史无冲突。这套流程覆盖了从 schema 编辑、SQL 生成、人工评审、本地应用到多环境部署的完整闭环也是 docs/database/migrations.md 与 db/README.md 反复强调的「Typical Workflow」的完整落地形态。若想进一步了解 schema 约定prefixed ID、snake_case映射、auth 表扩展方式可继续阅读 docs/database/schema.md环境变量与.env.{env}.local的完整语义见 docs/getting-started/environment-variables.md。赞分享后端前端【免费下载链接】react-starter-kitModern React starter kit with Bun, TypeScript, Tailwind CSS, tRPC, Stripe, and Cloudflare Workers. Production-ready monorepo for building fast web apps.项目地址https://gitcode.com/gh_mirrors/rea/react-starter-kit点击查看免费下载相关推荐Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进与迁移工作流Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进与迁移工作流 本指南以 Karakeep原 hoarder仓库中的官方后端前端移动开发AI 应用知识管理全文检索MCP 服务Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进、迁移生成与 Drizzle Studio 操作指南Karakeep 数据库迁移实战基于 Drizzle ORM 的 Schema 演进、迁移生成与 Drizzle Studio 操作指南 本篇技术指南聚焦当前后端前端移动开发AI 应用知识管理全文检索MCP 服务Drizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移Drizzle Kit 迁移生成器实战指南Schema 快照对比与自动 SQL 迁移 Drizzle Kit 是 Drizzle ORM 官方提供的 CLI后端数据库ORM上一篇终极指南如何用 Debugbar 快速优化 Ruby on Rails 应用性能下一篇如何快速上手Practical-Deep-Learning-for-Coders-2.07个计算机视觉实战项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
