Question

我进行了没有以任何方式接触给定表的迁移。运行它之后，删除了引用该表的3个外键，其对应的列从bigints更改为整数。

这导致了

我有一个在生产中运行的应用程序，其中A，B，C列作为具有外键的bigints
我进行了迁移，将它们设置为bigints和外键，
我没有进行迁移的操作，不会删除那些外键和
我没有将其从bigints还原为整数和
我的schema.rb在我的提交中将它们定义为整数（在意识到错误之前提交）

一个例子：

# the most recent migration related to the column
# but an old one (not only executed on dev branch)
def up
  # ...
  change_column :abc, :table_a_id, :bigint
  # ...

# development db/schema.rb
# ...
create_table "abc", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
  t.integer "table_a_id"
# ...

# production db/schema.rb
# ...
create_table "abc", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
  t.bigint "table_a_id"
# ...
add_foreign_key "abc", "table_a"
# ...

我已经跑过rails db:reset，但没有任何改变。

AFAIK，我无法创建迁移来更正这些更改，因为此类迁移将在生产中失败。它是否正确？如果是这样，我该怎么做以挽救提交并防止再次发生？我可以手动还原schema.rb吗？为何/如何发生？

Answer 1

关于回滚迁移的有用信息：

How to rollback a specific migration?

长话短说，是的，您可以重置数据库和schema.rb文件的结构。您可能会从删除的列中丢失任何数据，但是，如果要使您的schema.rb文件看起来正确，那么它会通过任何预部署挂钩，然后回滚并重置schema.rb文件是解决方法：

rake db:rollback

将还原您的最新迁移。如果此迁移不是您的问题，请尝试：

rake db:migrate:down VERSION=20100905201547

使用正确的版本时间戳记，该时间戳记存在于迁移文件名中。完成此操作后，将修复本地数据库，但架构文件仍将不同步。要解决此问题

rake db:schema:dump

最后，如果您仍然头痛，并且作为最后的解决方法，您可以

git checkout db/schema.rb

然后您将获得最新版本的db / schema.rb，它已推送到您正在处理的分支上。或者：

git checkout origin/master db/schema.rb

要将您的schema.rb文件重置为master。只要您不推动任何中断的迁移，并且您的schema.rb文件是正确的，那么您就不会为其他任何人破坏任何东西

Rails迁移更改了不相关的列

1 个答案: