У разработчиков DBIx::Class::Schema::Versioned есть мнение, что этот модуль - вчерашний день. О чём, кстати, почти прямо сказано непосредственно перед #GETTING_STARTED.
На мой взгляд, основной недостаток DBIx::Class::Schema::Versioned - необходимость описания обновления "с любой версии на любую", что требует n! (факториал от n) файлов с обновлением. Конечно, на практике до n! не доходит, но.... На практике это говорит о том, что при изменении перловой части схемы вы должны обеспечить наличие файлов для апгрейда со всех версих, присутствующих на продакшене, до текущей. Если не совсем понятно, то вот конкретный пример. Допустим, у вас на продакшене и в девелопинге схема версии 10. Вы сделали изменения, версия теперь 11, сделали файл апгрейда 10->11, закоммитили. Всё вроде хорошо. Но перед деплоем на продакшен вдруг обнаружилась ошибка. Ну, с кем не бывает. Получается что версию 11 на продакшен выкатывать нельзя. Не проблема - ошибку исправили, версию подняли, готовы закоммитить. Но теперь вам надо предоставить два файла обновлений: 10->12 и 11->12. Потому как у вас есть дев-среда, с версией 11, и продакшен, пока ещё с версией 10. При попытке сделать апгрейд на продакшене всё обломится, если не будет файла 10->12, так как DBIx::Class::Schema::Versioned не умеет использовать файлы промежуточных апгрейдов. Конечно, этого можно избежать, и обойтись одним обновлением - путём отката своей базы до предыдущей версии и внесения исправлений в изменение 10->11. Но это если у вас есть full-dump от версии 10. И даже если есть - это гемморой. Проще всё-таки сделать новый апдейт, который исправит ошибку и продакшен пропустит одну (или несколько) версий. А если у вас есть development, production и ещё и semi-production, на котором заказчик тестит вашу работу в "максимально приближённой среде" - то количество одновременно используемых версий растёт, а вместе с ним - и кол-во файлов апгрейда. Берите DBIx::Class::DeploymentHandler. Документация у него, правда, слегда замороченная, но в DBIx::Class::DeploymentHandler::Manual::Intro есть даже готовый install-скрипт. Его будет необходимо немного расширить для выполнения трёх основных операций: 1) проинсталлить служебные данные в существующую базу, 2) после изменения перл-файлов схемы сгенерить обновления в sql/ и 3) при наличии старой версии в базе и файлов новой версии в sql обновить базу. Уверен, что внимательное чтение мануала снимет все вопросы, если же нет - обращайтесь. 29 сентября 2011 г. 9:50 пользователь Alexander Q <[email protected]> написал: > http://search.cpan.org/~abraxxa/DBIx-Class-0.08195/lib/DBIx/Class/Schema/Versioned.pm#GETTING_STARTED > > Я списал свои скрипты генерирования апгрейда и собственно апгрейда > практически дословно отсюда. $schema->create_ddl_dir содержит всю магию. > > On 29.09.2011 09:44, Alex Povolotsky wrote: >> Добрый день, >> >> не поможет ли кто внятным рассказом, как делать версионированные схемы в >> DBIx::Class? Для апгрейда нужен файл апгрейда, который (вроде бы) можно >> сгенерировать автоматически - но нигде не сказано, как. >> >> Alex > > -- > Alexander Q mailto:[email protected] > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Sincerely yours, Oleg Kostyuk (CUB-UANIC) -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
