Миграция доктрины начинается в середине проекта
Я работаю с Symfony и Doctrine. В середине проекта мне нужно реализовать миграции Doctrine, потому что изменений в БД было слишком много, и мне нужен лучший способ справиться с этим. Как лучше всего начать миграцию, когда данные о продукте уже есть, и их нужно оставаться там и не трогать?
Мой план будет:
В моей тестовой системе
- отбросить все таблицы
- запустите php bin / console doctrine: migrations: diff
- Новый файл автоматической миграции, которым я стал, содержит все структуры таблиц моего текущего состояния.
- перейдите в таблицу "migration_versions" и добавьте идентификатор этой миграции, чтобы она не пропустилась при первом запуске миграции
- запустите миграцию php bin / console doctrine: migrations: migrate
Таким образом, у меня есть все структуры из моих сущностей, но я не буду уничтожать свои живые данные.
Что ты думаешь?
Ответы 2
Если уже есть некоторые данные о производстве, лучше всего сделать make:migration или doc:mig:diff из текущего состояния схемы. Это сгенерирует только необходимый sql, который обновит новые изменения, но ничего больше. Ваша первая версия миграции будет учитывать только sql для обновления с текущего состояния, а не с начала времен.
А также, как только вы это примените, вам нужно будет вносить все изменения в базу данных при миграции. Например, если вам нужно добавить поле, не допускающее значения NULL, вы обычно добавляете новое поле с ненулевым значением, затем заполняете все строки этого поля значением по умолчанию или вычисленным значением, а затем изменяете таблицу, чтобы поле не допускало значения NULL. . Миграции будут генерировать некоторый шаблонный код, чтобы облегчить вашу жизнь, но это также требует большой осторожности со стороны команды разработчиков. Всегда сначала проверяйте их в базе данных, от которой вы можете избавиться. И вы столкнетесь с ограничениями FK и множеством других проблем, но в основном вы должны решать их с помощью SQL.
Старая ветка здесь, но что я делаю в таких случаях:
- Резервное копирование базы данных разработчика (структура и данные, но с операторами создания таблиц, защищенными проверкой, поэтому они создаются только в том случае, если они еще не существуют)
- Отбросьте все таблицы, чтобы база данных была пустой
- Сгенерировать миграцию (поскольку база данных пуста, сгенерированная миграция будет содержать все команды, необходимые для генерации всей вашей схемы)
- Запустите миграцию, которую вы только что создали, чтобы построить схему
- Импортируйте тестовые данные из вашего дампа
Это вернет вас обратно с того места, где вы начали, но с первоначальной миграцией, которая может построить вашу схему из ничего.
Я бы добавил шаг 0. Запустите diff в существующей базе данных разработчика, чтобы убедиться, что схема соответствует той, которая будет создана на шаге 3. С существующим проектом у вас, вероятно, будет много мелких проблем, таких как размеры столбцов varchar, беззнаковые целые числа и тому подобное, которые неправильно выражены в коде. Обновляйте метаданные вашей сущности, пока разница не станет пустой.
Хорошее предложение, спасибо! Но мне нужно иметь это с самого начала, потому что моим модульным тестам нужна вся база данных и нужно выполнять все миграции с нуля, каждый раз развертывая их в битбакете.