Running Rails 4 with Postgres 9.4 in development and production. I've got a large table that has grown by migrations over time. Because of the many different columns on the table, I want to reorder things so that the columns are grouped more logically. In other words, some column elements naturally group together based on what information they capture.
I found a discussion on using after:
in a migration to reorder columns (using ALTER TABLE
in SQL), at this stack overflow discussion. I then went ahead and set up a migration to do that. After running the migration I notice that my schema.rb file hasn't changed. Looking at the columns in the database (postgres on development), nothing has changed there either.
Further research led me to the Postgres wiki, which states there is currently no support for altering column position in Postgres.
This isn't mission critical, but it would make life easier. My question is:
If I simply move lines in the
schema.rb
file up or down in order to position them as desired, will that cause any problems? Since I expect to provision any new database with rake db:schema:load, it wouldn't seem like that should break anything. Further, since the previous migrations aren't materially changed (just the order of columns they output to schema.rb) everything should be internally consistent, no?If that's a bad idea, can I simply go back into the earlier migrations, add the syntax for
after: :some_column
to each column element so they correctly set up the schema.rb file?
My assumption is that when I rebuild my production database from scratch with seed data, it will use the schema structure to correctly create the table in the desired order. Right now it's not a real, deployed database with end users, so it doesn't seem like an issue. Using option #1 above seems like the easiest solution, as long as it doesn't break anything.