Приветствую! Недавно возник вопрос про обработку данных в приложении. Поделитесь своим опытом, что вы в таком случае делаете.

1. Например нам нужно добавить какие-то данные в существующей таблице, предположим колонку, и на основании сложных вычислений (которые невозможно просто описать простым SQL запросом) протсавить там данные. Для примера, представим, что нужно с помощью внешнего сервиса проставить - доступен ли email адрес пользователя который указан в его профиле.

2. Нам нужно запустить обработку всех картинок хранящихся на сайте, и сделать ресайз в новом разрешении (база даных вообще не участвует в этом случае, предположим.

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

У меня нет цели отстоять свою точку зрения, а скорее разобраться в вопросе. Как это делается у вас. Возможно кто-то может дать отсылку к статье, книге.
Спасибо.

Первая миграция изменение структуры.
Вторая миграция заполнение данных.

_____________
Стимулятор ~yoomoney - 41001303250491

jetistyum, слушай Valick, он правильно говорит. Коллеги, не правы, миграции могут содержать данные. Миграция она на то и миграция, что бы ты смог восстановить необходимое тебе состояние СУБД на удаленной машине. А состояние это не только структура, но и данные в этой структуре. Да и если у вас проект не новый, то покопавшись в миграциях, ты стопудова найдешь добавление или изменение данных в миграции.

Другое дело если ты в миграцию пихнешь скрипт, то наверное это будет плохо. В таком случае я бы поступил так:
Задача 1
1. Миграция на изменение структуры
Задача 2
1. Скрипт для заполнения поля(ей) добавленного в миграции, если его нельзя сделать запросом
Задача 3
1. Код который будет использовать поле

Я не вижу проблем чтобы в миграциях изменять данные.
Но смысл миграций - восстановить нужную структуру БД с нуля.
А в пустой базе данных, где нет пользователей, нет картинок, эти миграции ничего не сделают.
А функционала повторного запуска миграции обычно нет, т.к. это противоречит идее.

Поэтому вот эти фишки, что у тебя, я бы в консольные команды поместил.

_____________
There never was a struggle in the soul of a good man that was not hard

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Спасибо за участие! уже столкнулся с тем, что это довольно дискуссионный вопрос.
Разработчики делятся на тех, кто считает что :

1. Миграция должна содержать изменения только схемы бд и не более.

2. Миграция может содержать изменения схемы и данных. но ни в коем случае не использовать слой сервисов. Буквально каждая миграция это чистый статический SQL.

3. Миграция может содержать изменения чего угодно, использовать сервисы для обработки данных и если нужно отправлять почту во время обработки.


На самом деле просто стоит рассматривать
а) Миграцию схемы
б) Миграцию данных
в) Миграцию доменной логики/бизнес правил

И все это тоже миграции. Главная задача миграции (с моей точки зрения) это привести приложение из состояния а в состояние б, которое нам нужно повторить на всех возможных серверах. будь то с базами данных, с файлами, с чем угодно еще.

Ведь даже если мы скажем что автоматическая конвертация всех картинок в нашем приложении это не имеет отношения ни к схеме бд ни к ее данным (ну предположим что это так) ... то это все равно не отменяет необходимости выполнить это. И к этой конвертации мы должны предъявить те же требования: идемпотентность и конвергентность.
скрипт конвертации после деплоя кода на сервер (или локальную машину любого другого разработчика) должен взять список файлов и обработать каждый из них по какому-то алгоритму.
А чтобы это заимплементить мы должны либо взять готовое решение которые уже сделаны для обычных миграций в любом фреймворке. (Yii/Laravel, Symfony) и максимум - положить это в папку отличную от "migrations". Либо повторно изобрести велосипед, и придумать свою логику для того же.
Поправьте меня, если я не прав.

зачем разработчиков делить по миграциям, у каждого просто свое понимание.