为什么在运行db：migrate for Rails之后会更新schema.rb？

Question

我的理解是，创建迁移的人也应该更新schema.rb。由于我已经完成了迁移，因此我也应该已经完成​​了更新后的schema.rb。但是，有时，schema.rb在运行bundle exec rake db:migrate之后会更新。

我当前的工作流程是：

1. git pull --rebase origin master --prune

2. rails s

3. 路轨告诉我要迁移

4. bundle exec rake db:migrate

5. 实现schema.rb更新

目前，我很确定我不应该签入更新后的schema.rb。我会通过git checkout origin/master db/schema.rb手动将其还原。

那么在这种情况下出了什么问题？同事在创建迁移后是否忘记运行迁移？我做错什么了吗？

Answer 1

据我所知，运行rails db：migrate后架构可能会由于以下原因而发生更改：

1. 同事没有提交schema.rb，因此当您获取并运行迁移时，会得到差异
2. 本地计算机上正在运行其他数据库版本。基于数据库的配置架构可能会相应更改。

运行git diff将帮助您了解运行情况。

Answer 2

schema.rb保留两个关键数据集：

1. 您的应用数据库结构中所有表的描述
2. 已应用的所有迁移的列表。

如果有新的开发人员加入您的团队，他们应该能够运行rake db:schema:load并立即获得最新的数据库结构。这比期望它们手动完成所有迁移要有效和可靠。

运行rake db:migrate，即使没有需要运行的未完成的迁移，也将始终重新生成db/schema.rb。大多数情况下，您不会注意到，因为文件会相同–但是在空白格式或列顺序上可能会有所不同。

最佳实践（IMHO）应该始终是在与已添加的所有迁移相同的提交中检入更新的db/schema.rb。

在获取或拉出分支到本地计算机时，运行rake db:migrate将根据本地数据库schema_migrations表中的记录应用需要运行的所有新迁移。此后，您的新db/schema.rb 应该与您下拉的那个相同–但是，如果不是，git diff会告诉您有什么不同。

然后您可以判断最佳行动方案是什么。如果唯一的区别是外观，我个人倾向于还原未上演的更改，并保持提交的版本不变，直到下一次迁移。

如果通过在db/structure.sql中指定config.active_record.schema_format = :sql切换到基于SQL的结构文件（config/application.rb），以上所有内容同样适用。