Нет, я не думаю, что вы сможете переписать миграцию ... если, конечно, вы не знаете, какой была метка даты для имени файла миграции.Если вы посмотрите на имена файлов ваших миграционных файлов в папке db, то заметите, что все они имеют метки.
Эта метка даты на самом деле хранится в поле базы данных, в которую вы пишете.Если вы проверяете свою базу данных, вы увидите таблицу schema_migrations и там вы найдете даты всех миграций, которые вы уже запустили.
Миграции - это сложная вещь, если вы продолжаете удалять миграциюфайлы.Я бы постарался не удалять старые миграции, если вы можете, особенно если они уже помещены в вашу базу данных. Если вы уже отправили их в базу данных, будет проще, если вы создадите новый файл миграции, чтобы исправить свою базу данных, а не собираться.обратно в старые миграции и рефакторинг .. это вызовет у вас мучительную боль, пытаясь сделать это таким образом ..
Прежде чем вы начнете разбирать его, сделайте резервную копию вашей базы данных heroku локально, прежде чем пытаться исправитьваши миграции
heroku db:pull
Если вы еще не отправили удаленные файлы миграции в ветку heroku и играете только с последним файлом миграции, попробуйте сначала откатить последнюю миграцию в heroku, исправьтемиграции, отодвиньте ее и попробуйте снова.
heroku rake db:rollback
Если вы пробовали это таким образом, и у вас все еще возникают проблемы, вы можете сделать следующее.Но будьте осторожны!Ошибка, которую вы видите, заключается в том, что вы пытаетесь отправить таблицу в свою базу данных, которая уже существует.Если вы добавите тег force => true в новую миграцию, вы можете эффективно поместить ее в свою базу данных, но на самом деле вы удалите существующую таблицу и создадите новую, так что все данные в вашей старой таблице будут потеряны.Но если вы согласны с этим и уверены, что ничего не сломаете, вы всегда можете использовать что-то подобное в начале своей миграции.
create_table "table_name", :force => true do |t|
t.column "name", :string....