I ran migrations which did not touch a given table in any way. After running it, 3 foreign keys which reference that table were removed and their corresponding columns changed from bigints to integers.
This has resulted in a situation where
- I have an application running in production with Columns A,B,C as bigints with foreign keys,
- I have migrations which set them up as bigints and foreign keys,
- I have no migration which removes those foreign keys and
- I have no migration which reverts them from bigints to integers and
- My schema.rb defines them as integers in my commit (committed before I realized the error)
an example:
# the most recent migration related to the column
# but an old one (not only executed on dev branch)
def up
# ...
change_column :abc, :table_a_id, :bigint
# ...
# development db/schema.rb
# ...
create_table "abc", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
t.integer "table_a_id"
# ...
# production db/schema.rb
# ...
create_table "abc", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
t.bigint "table_a_id"
# ...
add_foreign_key "abc", "table_a"
# ...
I have run rails db:reset
, and nothing changed.
AFAIK, I cannot create migrations to correct these changes, since such migrations would fail in production. Is this correct? If so, what can I do to rescue the commit and prevent this from happening again? Can I manually revert my schema.rb? And why/how did this happen?