后端数据库ORM【免费下载链接】sea-orm A powerful relational ORM for Rust项目地址https://gitcode.com/gh_mirrors/se/sea-orm点击查看免费下载导读本文基于 examples/tonic_example/migration/README.md 展开系统讲解 SeaORM 迁移器Migrator CLI的完整命令体系——从应用迁移、限量回滚到fresh/refresh/reset/status等运维命令并结合 examples/tonic_example 仓库中真实的迁移工程源码说明每个命令背后的执行语义与底层实现。读完本文你将能够在自己的 SeaORM 项目中熟练地驱动sea-orm-migration完成建表、回滚、重置和状态检查等全流程数据库版本管理。一、迁移器 CLI 在项目中的角色在tonic_exampleTonic gRPC SeaORM 示例中数据库结构由独立的migrationcrate 管理。该 crate 的入口文件 examples/tonic_example/migration/src/main.rs 非常简洁use sea_orm_migration::prelude::*; #[tokio::main] async fn main() { cli::run_cli(migration::Migrator).await; }整个 CLI 由sea_orm_migration提供cli::run_cli会解析命令行参数、根据DATABASE_URL建立数据库连接然后把命令分发给Migrator见 sea-orm-migration/src/cli.rs 中的run_cli_with_connection与run_migrate。也就是说所有迁移命令都通过cargo run触发无需安装额外二进制。Migrator在 examples/tonic_example/migration/src/lib.rs 中定义负责登记本 crate 的全部迁移文件pub struct Migrator; #[async_trait::async_trait] impl MigratorTrait for Migrator { fn migrations() - VecBoxdyn MigrationTrait { vec![ Box::new(m20220120_000001_create_post_table::Migration), Box::new(m20220120_000002_seed_posts::Migration), ] } }每次新增迁移文件后需要把对应的Box::new(...)追加到这个vec!中CLI 才能感知到它。二、运行前提数据库连接与依赖特性所有命令都依赖DATABASE_URL环境变量。从 sea-orm-migration/src/cli.rs 的源码可以看到连接串缺失时会直接报错let url cli .database_url .clone() .expect(Environment variable DATABASE_URL not set);因此运行前请先设置示例使用 SQLiteexport DATABASE_URLsqlite://./posts.db同时在 examples/tonic_example/migration/Cargo.toml 中sea-orm-migration依赖必须开启与目标数据库、异步运行时匹配的特性CLI 才能正常工作[dependencies.sea-orm-migration] features [ # Enable following runtime and db backend features if you want to run migration via CLI runtime-tokio-native-tls, sqlx-sqlite, ]其中runtime-tokio-native-tls对应 Tokio 异步运行时sqlx-sqlite对应 SQLite 后端。若使用 PostgreSQL 或 MySQL则相应替换为sqlx-postgres/sqlx-mysql并配置对应的运行时特性。三、应用迁移默认命令与up1. 应用所有待执行的迁移在migration目录下直接运行cargo run等价于显式写出cargo run -- upup会从当前已应用版本开始依次执行所有尚未应用的迁移的up方法。对应源码在 sea-orm-migration/src/cli.rsSome(MigrateSubcommands::Up { num }) migrator.up(db, num).await?,num为None时即全部应用。2. 限量应用前 N 个迁移cargo run -- up -n 10-n即--num指定本次最多应用的迁移数量。上例表示只应用前 10 个待执行迁移常用于分批次上线、逐步验证结构变更的场景。注意num是本次额外应用的数量而不是目标版本号。四、回滚迁移down1. 回滚最近一次应用的迁移cargo run -- down只回滚最近一次应用的那一批迁移调用其down方法。2. 限量回滚最近 N 个迁移cargo run -- down -n 10回滚最近 10 次应用的迁移。源码实现为Some(MigrateSubcommands::Down { num }) migrator.down(db, Some(num)).await?,down的执行顺序与up相反后应用的先回滚以保证依赖关系的正确性。五、全量重建fresh、refresh与reset这三个命令都涉及全量操作但语义不同务必区分清楚命令行为适用场景fresh先删除数据库中所有表再重新应用全部迁移开发环境彻底重建得到干净且完整的结构refresh先回滚所有已应用迁移再重新应用全部迁移保留版本记录的前提下重建回滚逻辑会被执行reset仅回滚所有已应用迁移快速撤销全部变更回到未迁移状态对应命令如下cargo run -- freshcargo run -- refreshcargo run -- reset在 sea-orm-migration/src/cli.rs 中三者分别被分派到Some(MigrateSubcommands::Fresh) migrator.fresh(db).await?, Some(MigrateSubcommands::Refresh) migrator.refresh(db).await?, Some(MigrateSubcommands::Reset) migrator.reset(db).await?,注意事项fresh是暴力重建——它直接删表而不执行任何down逻辑而refresh会依次执行每个已应用迁移的down再重新up。如果某个迁移的down实现不完整例如在down中抛错refresh/reset会失败此时可用fresh强制重置开发库。切勿在生产数据库上执行这三个命令中的任何一个。六、状态检查statuscargo run -- statusstatus会对比seaql_migrations表SeaORM 迁移的版本记录表中已应用的迁移与Migrator注册的全部迁移列出每个迁移的当前状态已应用 / 未应用便于上线前确认版本一致性。其分派逻辑同样位于 sea-orm-migration/src/cli.rsSome(MigrateSubcommands::Status) migrator.status(db).await?,七、迁移文件实战从建表到种子数据tonic_example的迁移工程包含两个迁移文件可以帮助你理解up/down的典型写法。1. 建表迁移examples/tonic_example/migration/src/m20220120_000001_create_post_table.rs 使用sea_orm_migration::schema::*提供的便捷函数创建post表manager .create_table( Table::create() .table(post) .if_not_exists() .col(pk_auto(id)) .col(string(title)) .col(string(text)) .to_owned(), ) .await其中pk_auto生成自增主键string生成变长字符串列。down则直接删表manager .drop_table(Table::drop().table(post).to_owned()) .await这样refresh/reset/down才能正确回滚。2. 种子数据迁移examples/tonic_example/migration/src/m20220120_000002_seed_posts.rs 展示了迁移中直接使用 ORM 写入数据的写法——通过manager.get_connection()拿到数据库连接再用实体层的ActiveModel插入初始数据let db manager.get_connection(); let seed_data vec![ (First Post, This is the first post.), (Second Post, This is another post.), ]; for (title, text) in seed_data { let model post::ActiveModel { title: Set(title.to_string()), text: Set(text.to_string()), ..Default::default() }; model.insert(db).await?; }其down则按标题批量删除种子数据post::Entity::delete_many() .filter(post::Column::Title.is_in(titles_to_delete)) .exec(db) .await?;这说明了迁移的一个重要设计原则down必须与up对称——up插入的数据要在down中删除up创建的表要在down中删除否则refresh/reset会产生残留或失败。八、命令速查表命令作用cargo run应用所有待执行迁移等同upcargo run -- up应用所有待执行迁移cargo run -- up -n 10仅应用前 10 个待执行迁移cargo run -- down回滚最近一次应用的迁移cargo run -- down -n 10回滚最近 10 次应用的迁移cargo run -- fresh删除所有表后重新应用全部迁移cargo run -- refresh回滚全部迁移后重新应用全部迁移cargo run -- reset回滚全部已应用迁移cargo run -- status查看各迁移的应用状态九、最佳实践建议开发环境优先使用fresh或refresh频繁调整表结构时一条cargo run -- fresh即可获得干净库需要验证down逻辑正确性时使用refresh。迁移文件命名保持时间戳前缀SeaORM 按文件名中的时间戳如m20220120_000001排序迁移保证执行顺序稳定。down实现要完整新增迁移时务必同时实现down否则一旦应用将无法通过refresh/reset回滚。种子数据迁移独立成文件像m20220120_000002_seed_posts.rs那样把数据填充与结构变更分离便于单独回滚或跳过。数据库选择通过 Cargo features 切换修改 examples/tonic_example/migration/Cargo.toml 中sea-orm-migration的特性即可切换 SQLite / PostgreSQL / MySQL无需改动迁移代码。以上命令均以tonic_example的迁移工程为实例验证同样的写法适用于任意基于sea-orm-migration的 Rust 项目——只需将main.rs中的migration::Migrator替换为自身工程的Migrator即可。赞分享后端数据库ORM【免费下载链接】sea-orm A powerful relational ORM for Rust项目地址https://gitcode.com/gh_mirrors/se/sea-orm点击查看免费下载相关推荐SeaORM Migration CLI 实战指南以 GraphQL 示例项目为例掌握数据库迁移全流程SeaORM Migration CLI 实战指南以 GraphQL 示例项目为例掌握数据库迁移全流程 导读 本篇技术指南以 examples/graphql后端数据库ORMSeaORM Migration CLI 实战指南基于 loco_starter 的数据库迁移命令全解析SeaORM Migration CLI 实战指南基于 loco_starter 的数据库迁移命令全解析 本指南以 examples/loco_starter后端数据库ORMSeaORM Migration CLI 完全指南从生成迁移到数据库版本管理的 8 大命令SeaORM Migration CLI 完全指南从生成迁移到数据库版本管理的 8 大命令 本指南以 SeaORM 迁移项目模板自带的 README.md h后端数据库ORM上一篇PaddleOCR 全览多语言 OCR 工具库的版本演进、模型矩阵与全流程能力解析下一篇ContraFlutterKit博客界面设计5种实用模板打造吸睛内容展示UI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端数据库ORM【免费下载链接】sea-orm A powerful relational ORM for Rust项目地址https://gitcode.com/gh_mirrors/se/sea-orm点击查看免费下载导读本文基于 examples/tonic_example/migration/README.md 展开系统讲解 SeaORM 迁移器Migrator CLI的完整命令体系——从应用迁移、限量回滚到fresh/refresh/reset/status等运维命令并结合 examples/tonic_example 仓库中真实的迁移工程源码说明每个命令背后的执行语义与底层实现。读完本文你将能够在自己的 SeaORM 项目中熟练地驱动sea-orm-migration完成建表、回滚、重置和状态检查等全流程数据库版本管理。一、迁移器 CLI 在项目中的角色在tonic_exampleTonic gRPC SeaORM 示例中数据库结构由独立的migrationcrate 管理。该 crate 的入口文件 examples/tonic_example/migration/src/main.rs 非常简洁use sea_orm_migration::prelude::*; #[tokio::main] async fn main() { cli::run_cli(migration::Migrator).await; }整个 CLI 由sea_orm_migration提供cli::run_cli会解析命令行参数、根据DATABASE_URL建立数据库连接然后把命令分发给Migrator见 sea-orm-migration/src/cli.rs 中的run_cli_with_connection与run_migrate。也就是说所有迁移命令都通过cargo run触发无需安装额外二进制。Migrator在 examples/tonic_example/migration/src/lib.rs 中定义负责登记本 crate 的全部迁移文件pub struct Migrator; #[async_trait::async_trait] impl MigratorTrait for Migrator { fn migrations() - VecBoxdyn MigrationTrait { vec![ Box::new(m20220120_000001_create_post_table::Migration), Box::new(m20220120_000002_seed_posts::Migration), ] } }每次新增迁移文件后需要把对应的Box::new(...)追加到这个vec!中CLI 才能感知到它。二、运行前提数据库连接与依赖特性所有命令都依赖DATABASE_URL环境变量。从 sea-orm-migration/src/cli.rs 的源码可以看到连接串缺失时会直接报错let url cli .database_url .clone() .expect(Environment variable DATABASE_URL not set);因此运行前请先设置示例使用 SQLiteexport DATABASE_URLsqlite://./posts.db同时在 examples/tonic_example/migration/Cargo.toml 中sea-orm-migration依赖必须开启与目标数据库、异步运行时匹配的特性CLI 才能正常工作[dependencies.sea-orm-migration] features [ # Enable following runtime and db backend features if you want to run migration via CLI runtime-tokio-native-tls, sqlx-sqlite, ]其中runtime-tokio-native-tls对应 Tokio 异步运行时sqlx-sqlite对应 SQLite 后端。若使用 PostgreSQL 或 MySQL则相应替换为sqlx-postgres/sqlx-mysql并配置对应的运行时特性。三、应用迁移默认命令与up1. 应用所有待执行的迁移在migration目录下直接运行cargo run等价于显式写出cargo run -- upup会从当前已应用版本开始依次执行所有尚未应用的迁移的up方法。对应源码在 sea-orm-migration/src/cli.rsSome(MigrateSubcommands::Up { num }) migrator.up(db, num).await?,num为None时即全部应用。2. 限量应用前 N 个迁移cargo run -- up -n 10-n即--num指定本次最多应用的迁移数量。上例表示只应用前 10 个待执行迁移常用于分批次上线、逐步验证结构变更的场景。注意num是本次额外应用的数量而不是目标版本号。四、回滚迁移down1. 回滚最近一次应用的迁移cargo run -- down只回滚最近一次应用的那一批迁移调用其down方法。2. 限量回滚最近 N 个迁移cargo run -- down -n 10回滚最近 10 次应用的迁移。源码实现为Some(MigrateSubcommands::Down { num }) migrator.down(db, Some(num)).await?,down的执行顺序与up相反后应用的先回滚以保证依赖关系的正确性。五、全量重建fresh、refresh与reset这三个命令都涉及全量操作但语义不同务必区分清楚命令行为适用场景fresh先删除数据库中所有表再重新应用全部迁移开发环境彻底重建得到干净且完整的结构refresh先回滚所有已应用迁移再重新应用全部迁移保留版本记录的前提下重建回滚逻辑会被执行reset仅回滚所有已应用迁移快速撤销全部变更回到未迁移状态对应命令如下cargo run -- freshcargo run -- refreshcargo run -- reset在 sea-orm-migration/src/cli.rs 中三者分别被分派到Some(MigrateSubcommands::Fresh) migrator.fresh(db).await?, Some(MigrateSubcommands::Refresh) migrator.refresh(db).await?, Some(MigrateSubcommands::Reset) migrator.reset(db).await?,注意事项fresh是暴力重建——它直接删表而不执行任何down逻辑而refresh会依次执行每个已应用迁移的down再重新up。如果某个迁移的down实现不完整例如在down中抛错refresh/reset会失败此时可用fresh强制重置开发库。切勿在生产数据库上执行这三个命令中的任何一个。六、状态检查statuscargo run -- statusstatus会对比seaql_migrations表SeaORM 迁移的版本记录表中已应用的迁移与Migrator注册的全部迁移列出每个迁移的当前状态已应用 / 未应用便于上线前确认版本一致性。其分派逻辑同样位于 sea-orm-migration/src/cli.rsSome(MigrateSubcommands::Status) migrator.status(db).await?,七、迁移文件实战从建表到种子数据tonic_example的迁移工程包含两个迁移文件可以帮助你理解up/down的典型写法。1. 建表迁移examples/tonic_example/migration/src/m20220120_000001_create_post_table.rs 使用sea_orm_migration::schema::*提供的便捷函数创建post表manager .create_table( Table::create() .table(post) .if_not_exists() .col(pk_auto(id)) .col(string(title)) .col(string(text)) .to_owned(), ) .await其中pk_auto生成自增主键string生成变长字符串列。down则直接删表manager .drop_table(Table::drop().table(post).to_owned()) .await这样refresh/reset/down才能正确回滚。2. 种子数据迁移examples/tonic_example/migration/src/m20220120_000002_seed_posts.rs 展示了迁移中直接使用 ORM 写入数据的写法——通过manager.get_connection()拿到数据库连接再用实体层的ActiveModel插入初始数据let db manager.get_connection(); let seed_data vec![ (First Post, This is the first post.), (Second Post, This is another post.), ]; for (title, text) in seed_data { let model post::ActiveModel { title: Set(title.to_string()), text: Set(text.to_string()), ..Default::default() }; model.insert(db).await?; }其down则按标题批量删除种子数据post::Entity::delete_many() .filter(post::Column::Title.is_in(titles_to_delete)) .exec(db) .await?;这说明了迁移的一个重要设计原则down必须与up对称——up插入的数据要在down中删除up创建的表要在down中删除否则refresh/reset会产生残留或失败。八、命令速查表命令作用cargo run应用所有待执行迁移等同upcargo run -- up应用所有待执行迁移cargo run -- up -n 10仅应用前 10 个待执行迁移cargo run -- down回滚最近一次应用的迁移cargo run -- down -n 10回滚最近 10 次应用的迁移cargo run -- fresh删除所有表后重新应用全部迁移cargo run -- refresh回滚全部迁移后重新应用全部迁移cargo run -- reset回滚全部已应用迁移cargo run -- status查看各迁移的应用状态九、最佳实践建议开发环境优先使用fresh或refresh频繁调整表结构时一条cargo run -- fresh即可获得干净库需要验证down逻辑正确性时使用refresh。迁移文件命名保持时间戳前缀SeaORM 按文件名中的时间戳如m20220120_000001排序迁移保证执行顺序稳定。down实现要完整新增迁移时务必同时实现down否则一旦应用将无法通过refresh/reset回滚。种子数据迁移独立成文件像m20220120_000002_seed_posts.rs那样把数据填充与结构变更分离便于单独回滚或跳过。数据库选择通过 Cargo features 切换修改 examples/tonic_example/migration/Cargo.toml 中sea-orm-migration的特性即可切换 SQLite / PostgreSQL / MySQL无需改动迁移代码。以上命令均以tonic_example的迁移工程为实例验证同样的写法适用于任意基于sea-orm-migration的 Rust 项目——只需将main.rs中的migration::Migrator替换为自身工程的Migrator即可。赞分享后端数据库ORM【免费下载链接】sea-orm A powerful relational ORM for Rust项目地址https://gitcode.com/gh_mirrors/se/sea-orm点击查看免费下载相关推荐SeaORM Migration CLI 实战指南以 GraphQL 示例项目为例掌握数据库迁移全流程SeaORM Migration CLI 实战指南以 GraphQL 示例项目为例掌握数据库迁移全流程 导读 本篇技术指南以 examples/graphql后端数据库ORMSeaORM Migration CLI 实战指南基于 loco_starter 的数据库迁移命令全解析SeaORM Migration CLI 实战指南基于 loco_starter 的数据库迁移命令全解析 本指南以 examples/loco_starter后端数据库ORMSeaORM Migration CLI 完全指南从生成迁移到数据库版本管理的 8 大命令SeaORM Migration CLI 完全指南从生成迁移到数据库版本管理的 8 大命令 本指南以 SeaORM 迁移项目模板自带的 README.md h后端数据库ORM上一篇PaddleOCR 全览多语言 OCR 工具库的版本演进、模型矩阵与全流程能力解析下一篇ContraFlutterKit博客界面设计5种实用模板打造吸睛内容展示UI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
