Как использовать fixtures при наличии данных в БД?

Question

[Евгений Комаров]

Здравствуйте, сейчас занимаюсь переписыванием старого desktop-legacy на symfony и столкнулся с небольшой проблемой.

В старом проекте есть справочники, которые хранятся в нескольких таблицах БД в виде nomer_spravochnika, code, value. Контроля целостности нет, вся логика обработки и хранения данных размазана между приложением и кодом в БД (тригеры, процедуры).

В новом проекте выношу каждый справочник в отдельную таблицу. Таких справочников уже больше 200, количество записей в них колеблется от нескольких десятков до нескольких тысяч. Я вынес данные справочных таблиц в csv файл, который загружаю на этапе миграций. Для тестирования отдельных модулей предполагается загрузка фикстур в БД с использованием DoctrineFixturesBundle и zenstruck/foundry. Мне нужно вместе с фейковыми данными для тестов иметь правильные данные для справочников, т.к. есть слой бизнес-логики (те же правила валидации), которая завязана на конкретных значениях в справочных таблицах.

Прошу пару советов, чтобы собрать мозги в кучу, а то уже запутался... Вопросов больше, чем ответов:

1. Логичен ли сам факт загрузки данных в таблицы на этапе миграций? Если нет, то что делать с этими данными - переносить загрузку в фикстуры? Тогда как их грузить на проде, ведь тащить на прод DoctrineFixturesBundle не совсем логично?...
   
2. Как при загрузке фикстур для свойств класса (ManyToOne) указать уже имеющиеся в БД данные?
   
3. Может есть вообще иной, более логичный путь...
   

Answer 1

[Дмитрий Гординский]

Пару лет назад столкнулся с похожей задачей, сидинг данных через миграции регулярно стрелял в ноги, и нужно было его вынести в отдельный функционал. Так и не понял почему DoctrineFixturesBundle продвигается как тула именно для тестирования, видимо неудачный нейминг оригинальной либы сыграл своё.
В доке к оригинальной либе среди юзкейсов упоминается в том числе и сидинг вне контекста тестов.
Doctrine Data Fixtures

Но, проверять на живом проекте я так и не решился и набросал на коленке свой силдер с нужным мне функционалом из 2-3 классов.

Как при загрузке фикстур для свойств класса (ManyToOne) указать уже имеющиеся в БД данные?

Если используются кодогенирируемые уникальные идентификаторы - можно их прописывать в константы, и использовать при сидинге родительской сущности, а потом её же использовать при сидинге потомков.
Если таких нет - хранить в константах те поля по которым оригинальную сущность получится найти и получить идентификатор.

Answer 2

[Vitsliputsli]

Фикстуры существуют для многократной заливки/перезаливки большого кол-ва различных слепков данных, что незаменимо при тестировании. При инстанцировании продовой (да вообще любой) базы данных, первоначальные данные вам понадобится залить только 1 раз, по-моему не стоит тут выдумывать сложных механизмов, просто залейте данные из файла прямо в БД. Если есть зависимые данные, можно заливать их сразу с указанными id, т.к. база пустая, и так как база только готовится и приложения не работают, то атомарность нам не важна.
В миграцию помещать данные не слишком удобно, в крайнем случае можно, но только те, которые не зависят от окружения, небольшие по объему, и которые не будут программно меняться.