我从最新的转储中恢复了我的数据库并尝试运行 rake 测试。不幸的是，有 30 个迁移未决。我的第一个想法是注释掉 30 个迁移代码中的每一个并运行“rake db:migrate”，但必须有一个更简单的解决方案。我使用 Rails 2.3.14 和 Postgresql 9.1.3。
问问题
3462 次
3 回答
6
如果您要从转储中恢复数据库，则该schema_migrations表应与其余表一起恢复。
这似乎表明您的schema_migrations表可能没有得到备份，这会导致您现在遇到的问题。
理想的解决方案是恢复包含正确的所有表的备份 - 包括schema_migrations.
即使您决定在短期内找到解决此问题的方法，但从长远来看，正确的解决方案是修改您的备份脚本以获取您需要的所有表，包括schema_migrations.
就现在要做什么而言，理想的解决方案可能是schema_migrations从您的数据库中仅备份一个表 ( )，然后将该数据导入您现在尝试加载的数据库中。那么您的迁移应该不再处于挂起状态。
用一个简单的表转储和加载脚本来做应该没问题。简单的 postgres gui PgAdmin ( http://www.pgadmin.org/ ) 还可以提供一些基本工具，用于转储然后加载单个表。
于 2012-05-14T09:51:29.160 回答
4
凯文是正确的。然而，他错过了一个关键点。
当您从备份恢复时，它会恢复 schema_migrations 表，该表跟踪需要运行的迁移。如果这 30 个迁移是在您从中恢复的数据库上运行的，它们就不会运行。
但是，您的代码比备份所代表的数据库快照提前了 30 次迁移。
如果我部署然后立即获取生产备份，这可能会发生在我身上。尽管迁移已在生产环境中运行，但我在部署之前的办公时间之前获得了备份。我通常喜欢等一天，然后得到第二天的备份。
或者，不要担心。您的备份是在这 30 次迁移之前进行的，但随后它们已被应用，因此迁移已确保您的架构与您的代码版本匹配。这是好事。
不要出汗，明天再刷新，当备份有你的变化时。
于 2012-05-14T10:37:21.897 回答
0
您还可以在 db 表中手动添加缺少迁移的时间戳，例如：
INSERT INTO "public"."schema_migrations"("version") VALUES ('20201212012345')
这应该与暂时取消迁移文件中的“创建”指令具有相同的效果。如果您在 git 的部署过程中运行迁移，注释掉意味着您必须将这些更改推送到 git。
如果您只是在暂存/开发环境中工作，直接修复数据库可能比推送这些更改更好，可能会混淆其他部署或开发人员。
于 2020-12-14T16:06:30.220 回答