Хорошие Миграции DB для CakePHP?

Я пытаюсь создать несколько сценариев миграции для CakePHP, но я столкнулся с проблемами со всеми в той или иной форме.

Пожалуйста, посоветуйте мне вариант миграции для Cake, который вы используете в прямом эфире и знаете работы.

Мне нужны следующие "функции":

Поддержка CakePHP 1.2 (например, миграция CakeDCs будет только вариантом, когда 1.3 стабилен, и мое приложение перенесено в новую кодовую базу)
Поддержка (или, по крайней мере, не останавливаться) Модели с другой конфигурацией базы данных.
Поддержка моделей в подпапках приложений/моделей
Поддержка моделей в плагинах
Поддерживать таблицы, не соответствующие соглашениям Cake (у меня есть несколько специальных таблиц, которые не имеют отдельного поля первичного ключа и должны содержать их).
Хорошо работает с автоматическим развертыванием через Capistrano и Git.

Мне не нужны файлы с версиями в стиле рельсов, а файл конфигурации версии git, который сравнивается в реальном времени с существующей схемой. То есть: мне нравится SchemaShell в Cake, кроме того, что он не совместим с большинством моих требований выше.

Я посмотрел и протестировал:

CakePHP Schema Shell http://book.cakephp.org/view/734/Schema-management-and-migrations
Миграции CakeDC http://cakedc.com/downloads/view/cakephp_migrations_plugin
миграции YAML http://github.com/georgious/cakephp-yaml-migrations-and-fixtures
joelmoss migrations http://code.google.com/p/cakephp-migrations

Ответ 1

Я попытаюсь обновить эту "тему" своими выводами после того, как вы быстро попробуете плагин Juan и все остальные, кроме тех, что указаны в CakeDC... так как у меня нет соответствующего приложения, обновленного для CakePHP 1.3, и эта миграция плагин требует 1.3

Я должен отметить, что комментарии о неудачах и плагинах, которые не работают для меня, следует читать в первую очередь как "не подходящие для МОИХ потребностей" или "ошибки, которые я сделал при их попытке". В некоторой степени некоторые могут читать такие комментарии, как просьба о пересмотре документации. Я не подразумеваю, что тестируемые плагины по своей сути ошибочны, ошибочны или сломаны. Я уверен, что все они работают при правильных обстоятельствах и для правильных рабочих процессов.

Сетка схемы CakePHP

Имеет ли простая концепция. Схема связана с кодом и SCM, используемым для управления его версиями.
Отлично работает. Этот момент:
Не подходит для автоматического развертывания. То есть Команда update может изменять только таблицы, а не обрабатывать новые или удаленные таблицы. Они обрабатываются своими командами оболочки, которые затрудняют развертывание Cap-стиля. Кроме того, при запуске обновлений с новой таблицей будут возникать ошибки, если script пытается "изменить" несуществующую таблицу. Я уверен, что если это предназначено или проблема, которую я испытываю. (Прошу в группе google еще не ответить)

Переходы CakeDC

Звучит так, будто они взяли оболочку схемы и "исправили" ее. Документы объясняют процедуру несколько более сложной (чтобы объяснить хотя бы), но она может работать так, как я хочу.

Переходы YAML, joelmoss и juan

Все они разделяют концепцию рельсов версий файлов и "подъем" и "сбой" между ними. Мне это нравится меньше, так как я не вижу ситуации для своих проектов, когда миграция схемы будет обновляться или откатываться, не делая то же самое с исходным кодом. Я также могу жить без возможности переноса существующих данных в миграции script, поскольку я предвижу это как очень редкое явление для меня.
Все это предполагает, что я не прикасаюсь к базе данных с помощью других средств, кроме сценариев миграции. Я не могу открыть свой любимый MySql-GUI и играть до тех пор, пока не буду счастлив, а затем создаю "diff" через эти скрипты. (По крайней мере, я не нашел документированных способов сделать это во время моих коротких тестов.) Мне нужно вручную записать изменения в файлах YAML или php. Поскольку я начинаю работать над существующим проектом с примерно 30 таблицами, мне не нравится идея переписать эту схему вручную. Но некоторые из этих плагинов не создали хороший начальный пункт файл со всеми моими таблицами. Возможно, это было связано с моим кратким тестированием и/или невозможностью найти документацию для такой функции. Я не погружался в исходный код для большинства из них.

В следующем шаге мы хотим обновить свой проект до CakePHP 1.3 и попробовать последний плагин. Но я не знаю, когда у меня будет время для этого. (т.е. никто не задерживает дыхание)

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

Ответ 2

Если вам нужна миграция Rails, используйте Rails Migrations... посмотрите на этот драгоценный камень https://github.com/thuss/standalone-migrations. Я использую этот драгоценный камень с cakephp в своей повседневной работе.

Ответ 3

У меня есть плагин, который делает его CakePHP 1.2, вы можете видеть в http://github.com/jrbasso/migrations

Он использует стиль торта, чтобы сделать все. Не использует yaml, использует объекты для определения таблиц. Вы можете импортировать модели из Cake без проблем...

Ответ 4

Я использовал плагин миграции CakeDC для 1.3.x и 2.x в производственных средах и был доволен. Есть некоторые ошибки, связанные с созданием миграции в версии 1.3.x, но их легко исправить.

Ответ 5

Используйте плагин 3.x Migrations.

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

Вы также можете легко использовать новый инструмент для существующих приложений 1.x и 2.x. Я только что опубликовал сообщение о как использовать 3.x Migration в приложениях 2.x, кстати.