Prevent "options" from create_table in rails 5 schema
Asked Answered
C

2

6

My Rails 5 schema.rb file has an options: section for each create_table that I do not want. What I have is:

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

but what I want is:

  create_table "accounts", id: false, force: :cascade do |t|

Since this is a generate file, I don't want to edit it manually.

The reason I don't want the options section is because for a fast TDD loop, I want to use SQLite in memory when RAILS_ENV=test but MySQL in development and production.

How do I prevent DB adapter specific options from being generated and put into the schema?

Convertite answered 10/8, 2016 at 16:30 Comment(4)
Having the same issue.Leung
All I have done to work around this is use RAILS_ENV=test db:migrate with test set to sqlite. Must be a better way.Convertite
@PeterSankauskas see solution below....Jada
Just hit this upgrading a large app from 4.2 to 5.2Quintin
J
2

Rails 5 broke the Schema dump format

In Rails 5 the core team decided to change the schema dump format and there were basically two issues with the new schema format:

1) the create_table statements now have options which are specific for the adapter, e.g. MySQL as in the OP's example.

2) the dumped columns do not show :limit statements if the value is the default value for the column type.

Why is that bad?

1) ActiveRecord is supposed to be DB agnostic, and some people use the schema files to load them into a different kind of database, e.g. load the schema file into a SQLite DB for faster testing.

SQLite does not understand the MySQL specific options, and breaks miserably.

2) Limits between different versions of the same kind of database could change over time, and limits could definitely change when you go from one DB to another DB.

Therefore it is not a good idea to just not show the actual value of the "default" limit.

Work Around

It is a terrible idea to monkey patch ActiveRecord. I hate having to do this, but that was the easiest way to get our schema files back to a DB-agnostic state, so we could do testing with SQLite.

If you are dumping your schema FROM MySQL on Rails 5.0, then you can fix it by adding these two files to your Rails 5.0 project:

config/initializers/active_record/schema_dumper.rb

config/initializers/active_record/connection_adapters/abstract/schema_dumper.rb

These two files contain the original code form the 5-0-stable branch of Rails, slightly modified to not do (1) and (2).

It's not pretty, but it will keep you generating the same dump format as before.

Hopefully the core team will fix the issue soon.

If you have a better solution, which allows cross-DB usage of schema files, please comment or post a better solution. I'm really not a big fan of monkey-patching :-(

Jada answered 7/2, 2018 at 23:14 Comment(0)
Q
0

The Rails core team is aware of this and locked the thread down because they were tired of hearing about it. I wouldn't look for a fix any time soon. While I agree that testing in the same db as you're prod environment as a rule of thumb, this is not always a good idea.

Forcing it is a really, really bad idea.

https://github.com/rails/rails/issues/26209

Quintin answered 11/10, 2018 at 14:30 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.