Как обсуждалось ранее , мы разрабатываем PHP-приложение вокруг Zend Framework, которое требует, чтобы его база данных обновлялась довольно часто и в режиме кросс-базы данных по мере продвижения по этапам разработки.
В настоящее время мы используем Rails Migrations для этого, хотя с ними в Ruby (и Ruby on Windows – это беспорядок), мы с трудом распределяем миграцию на клиентов, у которых есть установки на базе Windows. Даже в Linux доступ к базам данных MS SQL и Oracle с Ruby – это боль.
Мы хотим заменить Rails Migrations на Doctrine's, но они чувствуют себя очень незрелыми. Документации недостаточно, и в трекере есть некоторые ошибки, которые вызывают красные флаги о статусе проекта, такие как:
Рассматривая код, эти два фактически отбрасывают исходную таблицу или столбец и воссоздают его, не сохраняя данные. Это полный прерыватель транзакций, который заставляет меня думать, что никто не использует Doctrine Migrations.
Кроме того, я прочитал в документации, что миграции используют последовательную нумерацию (версия 1, версия 2 и т. Д.), Что делает их совершенно непригодными для разветвленной разработки, но тогда в документации DoctrineMigrationsBundle Symfony используются версии с датой, которые имеют смысл.
Кто-нибудь имеет опыт реального мира с инструментом или знает его статус развития?
Мы больше посмотрели на Doctrine Migrations и получили некоторое представление о его внутренней работе (и обновили ошибки, связанные с OP).
Основная проблема заключается в том, что у Доктрины принципиально иной подход к миграции. Он создает абстрактную модель из вашей схемы БД, а затем позволяет вам модифицировать эту модель. Эти изменения не влияют на базовую БД, но Doctrine использует их для вывода фактических изменений, которые должны быть сделаны в БД.
Это похоже на diff для баз данных. Это имеет очень неприятные последствия. Например, если вы переименовываете столбец в БД, операция над моделью выглядит так:
public function renameColumn($oldColumnName, $newColumnName) { $column = $this->getColumn($oldColumnName); $this->dropColumn($oldColumnName); $column->_setName($newColumnName); return $this; } Если вы используете эту функцию, а затем примените ее к Doctrine, она рассмотрит различия между старой и новой схемой (отсутствующие столбцы, добавленные столбцы и типы этих) и сделайте вывод о необходимости переименования существующего столбца или отбросить старый, и создать новый. Это означает, что Доктрина думает, что переименование столбца фактически совпадает с тем, что он отбрасывает его и снова создает, и поэтому очень глупо об этом.
Я думаю, что это плохой подход к миграции БД, потому что он не работает надежно. Весь смысл такого инструмента заключается в хранении данных во всех миграциях, и это не соответствует этому основному требованию.
Это говорит о том, что мы все равно используем его, потому что просто ничего лучше. Мы добавили умышленные сообщения об отказах в ненадежных операциях, чтобы не допустить, чтобы разработчики попали во многие подводные камни.
Честно говоря, миграция Доктрины лучше, чем большинство предложений; однако они немного незрелые, и трудно найти документацию. При этом, если держать их в ограниченном объеме, они работают очень хорошо.
Кроме того, с помощью любого инструмента миграции вы просто должны быть осторожны и не ожидаете, что он обеспечит магию.
Тем не менее, нет кросс-платформенного инструмента, который является полнофункциональным и доказанным в дикой природе как ликбаза. Кроме того, ни один другой инструмент, который я знаю, не содержит инструментария для документирования базы данных.
Следующий разговор о Liquibase должен предоставить вам достаточно информации, чтобы вы начали:
http://slidedecks.wilmoore.com/2012-confoo/painless-version-controlled-database-refactoring
Если вы смотрите на Doctrine 2, это может быть немного незрелым, особенно если вы хотите использовать только библиотеку Migrations. Из моего опыта работы с ним как с автономной библиотекой, а не с частью Doctrine2 ORM, это не прочный продукт. К их чести, это все еще Alpha, а Doctrine как полноценный ORM – довольно милая библиотека (и миграция очень хорошо работает как часть ее).
Я использовал Doctrine 1.X как полную ORM и миграцию во многих производственных средах, и она отлично работает.