Альтернатива Скрепка, которая работает в Rails 4 и Rails 6 - PullRequest
0 голосов
/ 31 октября 2019

Фон

  • У нас есть устаревший монолитный проект Rails 4.2. Назовите его «Классический».
  • «Классический» использует Paperclip для хранения ресурсов (фотографий, вложений и т. Д.) В сторонней системе.
  • Сейчас мы находимсяразбивая монолит на несколько микро-сервисов Rails 6. Назовите его «Новый».
  • «Классик» и «Новый» совместно используют одну и ту же БД.

Цель

  • Мы хотим прекратить использование Paperclip, потому что теперь оно устарело и вместо этого используем ActiveStorage.

Проблема

  • «Классика» и«Новым» придется жить некоторое время в одно и то же время.
  • «Новым» нельзя использовать Paperclip, потому что они устарели.
  • «Классическим» нельзя использовать ActiveStorage, потому чтодля этого требуется не менее Rails 5.2. («Классический» не может быть реально повышен до 5,2)
  • Таким образом, мы застряли в ситуации, когда «Новый» может использовать более новую технологию, но это требует изменения БД, с которым «Классик» не будет совместим си они используют одну и ту же базу данных, и «Классик» не может использовать более новую технологию.

Вопрос

  • Кто-нибудь еще имел дело стакая ситуация и смог найти подход, который работал? Или, может быть, у кого-то есть другая идея?

Моя (потенциально плохая) идея

  • Может быть, мы могли бы пойти дальше и реализовать все в «Новом», чтобыиспользуйте ActiveStorage. Мы могли бы предоставить некоторые конечные точки RESTful, которые позволили бы получать / создавать / обновлять / уничтожать сторонние размещенные ресурсы. Затем в «Классике», где бы ни использовался Paperclip, мы могли бы просто заменить эту логику и заставить ее делать вызовы RESTful нашим новым конечным точкам в «Новом». Наряду с этим нам также необходимо разработать стратегию для идентификации каждого актива, управление которым осуществлялось с помощью Paperclip, а затем создать эквивалентные записи в новой схеме ActiveStorage. Таким образом, логика «New» сможет получить доступ к прошлым активам. Я не уверен, что это реалистичный подход и, возможно, у него есть серьезные недостатки, которые я пропускаю, но это была мысль.

1 Ответ

0 голосов
/ 08 ноября 2019

Используя эту Скрепку для документа 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), но это битва за будущий день.

Вот так я и сделал. Определенно не говорю, что это лучший или даже правильный путь, но это способ, который в конечном итоге работал на меня. Просто хотел поделиться этим на случай, если кто-то еще столкнется с подобной ситуацией в будущем. Кроме того, большое спасибо человеку, который немедленно отклонил вопрос, не предоставив никакой обратной связи вообще. Вы были реальной помощью.

...