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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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