Question

我的Rails 5 schema.rb文件包含我不想要的每个options:的{{1}}部分。我所拥有的是：

create_table

但我想要的是：

  create_table "accounts", id: false, force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8" do |t|

由于这是一个生成文件，我不想手动编辑它。

我不想要create_table "accounts", id: false, force: :cascade do |t|部分的原因是因为对于快速TDD循环，我想在options中使用SQLite但在开发和生产中使用MySQL。

如何防止生成数据库适配器特定选项并将其放入架构？

Answer 1

Rails 5打破了Schema转储格式

在Rails 5中，核心团队决定更改架构转储格式，新架构格式基本上存在两个问题：

1）create_table语句现在具有options，这些语句特定于适配器，例如MySQL就像OP的例子一样。

2）如果值是列类型的默认值，则转储列不会显示:limit语句。

为什么那么糟糕？

1）ActiveRecord应该是与数据库无关的，有些人使用模式文件将它们加载到不同类型的数据库中，例如，将模式文件加载到SQLite DB中以加快测试速度。

SQLite不了解MySQL特定的选项，并且惨遭打破。

2）同一类型数据库的不同版本之间的限制可能会随着时间的推移而发生变化，当您从一个数据库转到另一个数据库时，限制肯定会发生变化。

因此，不显示“默认”限制的实际值不是一个好主意。

修补ActiveRecord是个糟糕的主意。我讨厌必须这样做，但这是让我们的模式文件恢复到与数据库无关的状态的最简单方法，因此我们可以使用SQLite进行测试。

如果要在Rails 5.0上转储模式FROM MySQL，然后你可以通过将这两个文件添加到你的Rails 5.0项目来修复它：

这两个文件包含Rails的5-0-stable分支的原始代码，略微修改为不执行（1）和（2）。

它不漂亮，但它会让你生成与以前相同的转储格式。

希望核心团队能尽快解决问题。

如果您有更好的解决方案，允许对架构文件进行跨数据库使用，请发表评论或发布更好的解决方案。我真的不喜欢猴子补丁： - （

Answer 2

Rails核心团队意识到了这一点，并锁定了线程，因为他们厌倦了对此的了解。我不会在短期内寻求修复。虽然我同意作为经验法则在与生产环境相同的数据库中进行测试，但这并不总是一个好主意。

强迫它是一个非常非常糟糕的主意。