«Финкс» и несколько БД

Несколько месяцев назад мне потребовалось подобрать ПХП-инструмент миграций БД для проекта на «Битриксе». Одним из требований была поддержка нескольких баз данных.

За время поиска я рассмотрел такие варианты, как «Илюминейт», миграции «Доктрины» и различные опенсорсные «битриксовые» (и не только) поделки. Но по соображениям простоты использования и функциональности, выбор пал на «Финкс»: он не привязан ни к какому фреймворку, может работать с шардами БД и имеет интуитивно понятное АПИ. Однако, АПИ на столько простое, что по началу к нему нужно привыкнуть. Но обо всём по порядку.


Phinx

«Финкс» — опенсорсная ПХП-библиотека для миграций БД, разрабатываемая Робом Морганом. Библиотеку можно применять в любом ПХП-проекте, независимо от используемого в нём фреймворка. Единственное, что «Финкс» тянет с собой со стороны — это несколько компонентов «Симфони», обеспечивающих консольное взаимодействие с мигратором БД.

Поддерживаемые по-умолчанию БД: MySQL, PostgreSQL, SQLite, SQL Server. Кроме этого, есть возможность зарегистрировать свои адаптеры.

АПИ

У библиотеки приятное АПИ в классе миграций. Посмотрите пример из документации:

public function change()
{
        // create the table
        $table = $this->table('user_logins');
        $table->addColumn('user_id', 'integer')
              ->addColumn('created', 'datetime')
              ->create();
}

В версии 0.2.0 был введён метод change(), логически объединяющий в себе выполнение и откат миграции. В случае отката, «Финкс» проанализирует произведённые действия при выполнении миграции и выполнит обратный алгоритм. Поддержка классических методов up() и down(), при этом, осталась.

Несколько БД

Официально, в документации нет ни слова о поддержке multiple database, и даже заведена на «Гитхабе» issue по этому поводу. Однако, решение нашлось без особого труда, стоило лишь немного изучить структуру и конфигурацию библиотеки. Рецепт прост и сейчас мы его рассмотрим. Полагаю, что с документацией «Финкса» вы уже знакомы.

Для каждой БД, миграции которой необходимо покрыть «Финксом», создаётся конфигурационный файл. Таким образом, получаем ряд yml-файлов:

Важно прописывать в конфигах для каждой базы уникальное название таблицы логов миграций (параметр default_migration_table), что бы у вас была возможность при необходимости хранить таблицы двух шардов в одной БД. В противном случае, «Финкс» будет записывать логи двух шардов в одну таблицу, что рано или поздно приведёт к их конфликту. И конечно же, нужно складывать файлы миграций в отдельные каталоги под каждую БД.

Что бы упростить выполнение миграций и ускорить добавление конфигов новых БД, вы можете написать свою реализацию консольной команды выполнения миграций, которая будет искать в каталоге конфигов yml-файлы, и уже для каждого из них по очереди запускать выполнение миграций. Пример моей команды можете найти на «Гисте».

Ваш фреймворк + «Финкс»

«Финкс» без проблем можно дополнить функционалом фреймворка, на котором построен ваш сайт. Для этого достаточно разработать консольное приложение, если его ещё у вас нет, которое будет «поднимать» фреймворк, а затем регистрировать в нём консольные команды «Финкса».

Фактически, консольное приложение представляет собой ПХП-файл, запускаемый из консоли, в котором инициализируется ядро фреймворка и подключаются доп. библиотеки.

Волею судеб, в моём случае в связке с «Финксом» используется «Битрикс». Благодаря этому, операции над инфоблоками, пользователями, группами и пр. «битриксовыми» структурами без проблем мигрируются с площадки на площадку.

Недостатки

Учитывая, что «Финкс» ещё не дошёл даже до версии 1.0.0, назвать минусами то, что было обнаружено мною за несколько месяцев его использования на паре проектов нельзя. Библиотека имеет хороший потенциал, и для первых версий выглядит достойно.

Поделиться
Отправить
Запинить
Популярное