汇总迁移？
据我了解，迁移的目的是让您可以在开发的最后阶段将数据库恢复到已知状态。
现在我仍在“充实”我的第一个 Rails 应用程序，我想知道是否可以将我的迁移汇总为更大的迁移而不是进行数十个更改。
As I understand it the point of migrations is so you can revert the database back to a known state during the last stages of development.
Right now I'm still "fleshing" out my first Rails app and I'm wondering if its ok to roll up my migrations into bigger ones rather than dozens of changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
迁移的要点是，您基本上拥有数据库更改的日志，以便其他开发人员可以知道进行了哪些更改，或者确保您的生产环境获得您在开发过程中所做的相同更改。
至于你的问题：当然。如果您创建一个新模型，然后几分钟后决定“此列可能只是一个字符串而不是文本”，请回滚迁移并更改该列，然后再次迁移。无需创建新的迁移。
除非您已经将之前的迁移提交到可能已被其他开发人员获取的源代码管理，或者您已经在生产服务器上应用了迁移。那么你应该使用新的迁移。
The point of migrations is that you basically have a log of database changes, so then other developers can know what changes have been made, or to make sure your production environment gets the same changes you made during development.
As for your question: sure. If you create a new model, and then after a few minutes decide "this column could just be a string instead of text", roll back your migration, and change the column and then migrate again. No need to create a new migration.
Unless you've already committed the previous migration to source control that may have been fetched by other developers, or you've already applied the migration on the production server. Then you should use a new migration.
作为 rspeicher 的附录，我将限制限制为是否已发布迁移，而不是是否已将其提供给其他开发人员。如果它仍然是预发布的，那么可以通过使用正在使用的 SCM 的 post-fetch 挂钩来通知开发团队是否需要对主代码存储库的任何更新运行迁移。任何配置管理更改都是如此，而不仅仅是迁移。例如，更改初始化程序文件夹中某些内容的实现可能对开发模式下正在运行的脚本/服务器实例没有影响。对于大多数技术中的大多数团队以及某些持续集成的配置来说，这最终是一个必要的机制。或者，您需要团队中良好的沟通渠道，以确保每个人都知道配置更改和重新启动是必要的。
As an addendum to rspeicher, I limit the constraint to whether a migration has been released, not to whether it has been made available to other developers. If it's still pre-release, then the development team can be informed of any need to run migrations for any updates of the master code repository by using post-fetch hooks for the SCM being used. This is true of any configuration management change, not just migrations. For example, changing an implementation of something in the initializers folder may have no effect on a running instance of script/server in development mode. This is a ultimately a necessary mechanism for most teams in most technologies as well as for some configurations of continuous integration. Or, you need excellent communications channels in the team to make sure that everyone knows that a configuration change and restart is necessary.