Используя эту Скрепку для документа ActiveStorage Migration , я смог найти удачное решение.
Вот что я сделал.
- В
New
я построил миграцию для добавления таблиц 2 ActiveStorage
. - Запустил миграцию.
- Настроил класс
ConvertToActiveStorage
(предоставлен в связанном документе по миграции), чтобы выполнить итерациюповерх моих «скрепленных» предметов и, в свою очередь, создайте эквивалентные ActiveStorage
записи. Примечание :: Вместо того, чтобы запускать ConvertToActiveStorage
как миграцию, я настроил его на запуск в качестве задачи Rake. - Выполнение логики
ConvertToActiveStorage
в Classic
. - Обновленомодели в
New
для начала работы с ActiveStorage
объектами (а не со старыми объектами "Paperclipized"). В основном изменилось что-то вроде :: has_one :photo, dependent: :destroy
на has_one_attached :photo
- В
Classic
, добавлены обратные вызовы after_create
, after_update
и after_destroy
на моделях Paperclipized
. Эти обратные вызовы отвечают за создание / обновление / уничтожение эквивалентных ActiveStorage
записей. Это позволяет Classic
('Paperclipized') и New
('структура ActiveStorage') существовать одновременно дольше. Поэтому, когда кто-то входит в Classic
и добавляет новый пользовательский образ, обратный вызов также обрабатывает и создает эквивалентные ActiveStorage
записи, чтобы New
мог взаимодействовать с пользовательским изображением. Та же идея для обновления и удаления. В конце концов, когда New
имеет возможность создавать / обновлять / уничтожать изображения, мне нужно будет предоставить обратные вызовы, чтобы пойти другим путем (ActiveStorage
до Paperclip
), но это битва за будущий день.
Вот так я и сделал. Определенно не говорю, что это лучший или даже правильный путь, но это способ, который в конечном итоге работал на меня. Просто хотел поделиться этим на случай, если кто-то еще столкнется с подобной ситуацией в будущем. Кроме того, большое спасибо человеку, который немедленно отклонил вопрос, не предоставив никакой обратной связи вообще. Вы были реальной помощью.