Можно ли использовать миграции Doctrine в производственных приложениях? - PullRequest
Новая
       11

Можно ли использовать миграции Doctrine в производственных приложениях?

14 голосов
/ 30 марта 2012

Как уже обсуждалось , мы разрабатываем PHP-приложение для Zend Framework, которому необходимо обновлять свою базу данных довольно часто и в рамках кросс-базы данных по мере продвижения по этапам разработки.

В настоящее время мы используем Rails Migrations для этого, хотя из-за того, что они в Ruby (а Ruby в Windows - беспорядок), нам трудно распространять миграции среди клиентов, у которых установлена ​​Windows.Даже в Linux доступ к базам данных MS SQL и Oracle с помощью Ruby является проблемой.

Мы хотим заменить Rails Migrations на Doctrine, но они кажутся очень незрелыми.Не так много документации и есть некоторые ошибки в трекере, которые поднимают красные флаги о статусе проекта, такие как:

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

Кроме того, я прочитал в документации, что миграции используют последовательную нумерацию (версия 1, версия 2 и т. Д.), Что делает их совершенно непригодными для ветвленияразработки, но затем в документации DoctrineMigrationsBundle Symfony используются версии на основе даты, которые do имеют смысл.

Кто-нибудь имеет реальный опыт работы с инструментом или знает разработкустатус этого?

Ответы [ 3 ]

14 голосов
/ 18 июня 2012

Мы больше изучили Doctrine Migrations и получили некоторое представление о его внутренней работе (а также обновили ошибки, связанные с OP).

Основная проблема заключается в том, что в доктрине принципиально иной подход к миграции. Он создает абстрактную модель из вашей схемы БД, а затем позволяет вам изменить эту модель. Эти изменения не влияют на базовую БД, но Doctrine использует их, чтобы вывести фактические изменения, которые необходимо внести в БД.

Это похоже на diff для баз данных. Это имеет некоторые очень неприятные последствия. Например, если вы переименуете столбец в БД, операция с моделью будет выглядеть так: 

public function renameColumn($oldColumnName, $newColumnName)
{
    $column = $this->getColumn($oldColumnName);
    $this->dropColumn($oldColumnName);

    $column->_setName($newColumnName);
    return $this;
}

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

  • Если вы переименуете один столбец и больше ничего не измените, он выдаст команду «переименовать» в СУБД.
  • Если вы переименуете столбец и измените его тип (скажем, varchar (80) на varchar (100)), он отбросит его и создаст заново.
  • Если вы переименуете 2 столбца и ничего не измените, он будет паниковать, отбрасывать их обоих и воссоздавать их (алгоритм diff такой элементарный)

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

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

7 голосов
/ 31 марта 2012

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

Кроме того, с любым инструментом миграции вы просто должны быть осторожны и не ожидать, что он обеспечит магию.

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

Следующий доклад о жидкостибазе должен предоставить вам достаточно информации, чтобы начать работу:

http://slidedecks.wilmoore.com/2012-confoo/painless-version-controlled-database-refactoring

2 голосов
/ 02 апреля 2012

Если вы смотрите на Doctrine 2, то он может быть немного незрелым, особенно если вы хотите использовать только библиотеку Migrations.Исходя из моего опыта работы с ней как с автономной библиотекой, а не с частью Doctrine2 ORM, она не является надежным продуктом.К их чести, это все еще Alpha, а Doctrine как полноценный ORM - довольно приятная библиотека (и миграции работают очень хорошо как ее часть).

Я использовал Doctrine 1.X в качестве полного ORMи Миграция во многих производственных средах, и она прекрасно работает.

...