А еще dto в обе стороны вроде тоже про это.

в общем повесила событие PRE_SUBMIT с обновлением списка, подскажите, как в событии формы получить исходные данные для поля? типа $event->getData() ?

чтобы проверить, значение новое, или было в исходном списке

есть холиварный вопрос.
У нас есть табличка юзеров, в нее добавляется новая колонка. Колокна RefferalCode которая должна быть уникальной для каждого пользователя.
А дальше есть два мнения.
1. колонку нужно добавить миграцией, а заполнить php командой вызвав ее руками
2. колонку нужно добавить миграцией и в миграции  же заполнить.

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

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

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

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

мне кажется можно делать добавление данных и в миграциях (в конце концов когда ты пишешь default null это то же самое, что фигачить данные)
но есть момент - когда добавляешь данные нужно чтобы не было зависимостей от каких-то других частей системы. Типа там сущностей доктрины например и другие зависимости. Потому что миграции - это историческая хрень.
Ну и да, как выше написали переиспользовать изменение стейта таблиц может быть удобно

то есть представь, что ты генерируешь идентификатор для строки при помощи ramsey uuid. Вроде бы всё замечательно, миграции проходят - круть.
Проходит 2 месяца, вы решаете использовать symfony uuid и выкидываете зависимость ramsey. А потом радостно запускаете миграции и они падают.

А что будет если к вам в команду придет новый разработчик, который накатит ваши миграции с самой первой. Ему нужны будут эти referalCode заполненые? Как он их заполнит?

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

Он наверное накатит последний дамп базы где они будут или с 0, где вообще ничего еще нет

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

мне кажется тут то же самое будет что и добавленгие новых строк в таблице в уже работающем проекте

с другой стороны миграции можно поправить 🤔

это зависит от того, как заполняются эти коды непосредственно в приложении. Тут уже от логики приложения зависит

в приложении они автогенерируются для новых пользователей при регистрации

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

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

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