Евгений Вольф: Ну, к примеру. Раньше поле хранило путь до картинке, а теперь должно хранить json с метаданными (размер, дата загрузки и прочая фигня). Если так нужно согласование с администратором БД. то для этого есть pull-реквесты.
Сомнительный у вас воркфлоу. С точки зрения бюрократии - возможно и хорошо, а с точки зрения разработки - ад :)
Евгений Вольф: я имею в виду ситуацию, когда я пилю фичу, в которой надо как-то изменить БД. Т.е. разработка тут заключается в двух шагах, грубо говоря: изменить БД и, собственно, реализовать логику с использованием этих изменений. Т.о. может получится так, что база изменена, а логика фичи еще не реализована (т.е. самого кода в VCS еще нет).
> Это гораздо удобнее, чем получать "пустую" базу после миграций, т.к. новое поле может быть не только создано, но и заполнено сразу.
А что мешает как-то инициализировать это поле в миграции?
> база для всех одна, доступна либо локально, либо через интернет (по ситуации) и там уже ничего переносить не нужно, данные централизованы
Не понятно, как в вашем случае вы запиливаете фичи, для которых, к примеру, нужны доп. поля в БД или того хуже, надо поменять существующие? База же одна на всех. Пока фичу не запилите, другие разработчики будут с невалидной БД?
А вообще сомнительное желание. В случае смены дизайна придется перегенерировать все картинки. Не то чтобы это сложно, но в случае с фильтрами вообще не придется ничего делать. А лучший код - это не написанный код :)
Я понимаю, что есть вариант реализовать нужную выборку через свои собственные методы в репозитории
Только надо указывать и JOIN, и SELECT. Если указать только JOIN, то данные не будут гидрированы и при попытке доступа к свойству все равно будет генерироваться дополнительный запрос.