It seems to me the generated schema.rb file in Rails does not retain
table type (and probably other characteristics).
MySQL 5, Rails 1.2.5
Working with some legacy tables here, and experimenting with how
migrations are going to interact, and how best to initialize a rails
project using a legacy db as starting point for migrations.
Rather than hand coding a boatload of rails-style create_table tasks, I
figured I could cheat and initialize an empty database using legacy
CREATE statements, and use db:migrate to create them for me in
I created my db, used my legacy CREATE statements to initialize all
tables, added a single migration to create the standard Rails sessions
table, then ran the rake task. That of course generated the schema.rb
I then deleleted all tables and the create_session migration, and I used
the create_table and add_index statements from schema.rb to create a new
001 migration called create_all_tables
In reviewing my tables, I notice they're all InnoDB now instead of
After reading through some docs about :options, I also suspect that if I
didn't already have utf8 defined, that whatever CHARSET I had defined
would have been nuked too.
This seems to be significant shortcoming. I would think that schema.rb
should be generated with appropriate options for table type, character
set, collations and probably other stuff too.
I know I can override it by editing the create_table statement myself,
but I shouldn't have to.
Am I missing something? Is this a known "defect" in how schema.rb is
generated? I know Rails can detect these attributes of existing tables
(I've done it in other similar work of my own). Is this a judgement call
for database neutrality? If so, still seems to me there should be some
capability to generate schema.rb based on what actually exists, because
as it is, it's not preserving what the schema really is.