[Moscow.pm] Версионированные схемы в DBIx::Class - кто-нибудь делал?

[Oleg Kostyuk]

У разработчиков 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 <qalex на ashmanov.com> написал:
> 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:qalex на ashmanov.com
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)