Можете ли вы создать «временную» модель при миграции Rails?
У меня есть проект Rails 2, который имеет отношение "многие-многие" через Таблица соединений. Назовем таблицы A, B и ABJ, где ABJ имеет свойства a_id и b_id (вместе с не относящимся к этому вопросу id и {created, updated} _at ).
То, что я хочу сделать
К сожалению, эта взаимосвязь с самого начала была создана неправильно и должна была быть просто один-много (A has_many B's, B own_to A). Итак, я создал миграцию вверх , которая повторно связывает B напрямую с A. В основном так: 1) add_column a_id в B, 2) для каждого ABJ, поместите abj.a.id в abj. b.a_id, 3) drop_table: abj. Это прекрасно работает.
Я также создал «обратную» операцию при миграции вниз , чтобы вернуться, если мне нужно (1) create_table abj, 2) для каждого B создать новый abj, такой, что abj.a_id = b.a_id и abj.b_id = b.id, 3) remove_column a_id из B). Это тоже отлично работает.
Проблема
Наряду с «повторным связыванием» этого отношения с «один-многие» есть ожидание, что неиспользуемый ресурс соединения ABJ исчезнет, то есть при удалении модели, контроллера, тестов и т. Д.Проблема в том, что если мне нужно вернуться, выполнение миграции вниз не сработает, потому что на шаге 2 (для каждого B создайте новый abj) больше не будет любой класс ABJ
Так есть ли способ создать «временную» модель в рамках миграции только для манипулирования данными в БД? Или вы просто требуете, чтобы человек, выполняющий миграцию, был уверен, что эта модель существует, прежде чем запускать ее? Потому что, если миграция вниз завершится неудачно на шаге 2, тогда на шаге 1 уже будет создана таблица abj , и тогда вам придется вручную удалить ее или закомментировать шаг 1 код в миграции, прежде чем запускать ее снова (а затем раскомментируйте его).
Интересно, есть ли какое-нибудь хорошее решение этой проблемы.