Возможность учитывать версионность и накатывать миграции для конкретного модуля

[Fedott]

Отсюда: http://forum.kohanaframework.org/discussion/comment/77610#Comment_77610

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

[Fedott]

Сделал. Pull request #8

[slider23]

Отлично сделано, респект :) Да еще и с тестами ! Имхо, можно в phpdoc смело добавляться как автор. :)

Только одно но. Миграции часто нужно накатывать индивидуально по каждому модулю. Например, вышла новая версия модуля комментариев - надо накатить изменения. А в application, допустим, мы уже сделали кучу своих миграций, и version у нас позднее, поэтому при db:migration ничего не произойдет.

Поэтому надо добавлять в таблицу schema_version столбец module с дефолтным значением application - хранить version для каждого модуля. Добавлять в db:version ключ module. И, соответственно, учитывать его при миграции.

[biakaveron]

Может, сразу сделать универсальный вариант? Не модули, а какая-то область кода. Не --module, а --scope или --schema

[slider23]

Я сейчас не могу придумать, зачем могут понадобиться области.. Ведь все, что не относится к модулям - это относится к твоему application, по идее ? Вряд ли будет нужен комплект миграций для двух модулей одновременно - если такое происходит, то проще эти модули в один объединить, раз у них такая сильная зависимость.

[Fedott]

Спасибо, за похвалу =)

По существу: сейчас миграции между собой имеют связь только в виде timestamp, и очерёдность их выполнения обусловлено только тем что у кого timestamp меньше та миграция выполниться раньше. При этом при команде db:migrate применяются все миграции которые не были применены раньше, даже если их timestamp меньше чем текущая последняя выполненная миграция.

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

[slider23]

при команде db:migrate применяются все миграции которые не были применены раньше

А где хранится отметка, применялась данная миграция или нет ?

[biakaveron]

Эх, если бы всегда логически автономные сущности были выделены в отдельные модули... Крик души ))

[Fedott]

где хранится отметка, применялась данная миграция или нет ?

Отметка хранится в базе. В базе лежат timestamp отметки всех применённых миграций. Дело в том что команда db:version, показывает по сути просто последнюю применённую миграцию с самым большим значением timestamp. По сути то значение которое выводит эта команда, почти никак не влияет на то какие миграции будут применены. Как-то так. А вот про то что команда db:version по сути не информативна тут, действительно можно было бы выводить у какого модуля какая миграция была применена последней.

[slider23]

Да, поэкспериментировал, вижу, я раньше почему-то думал, что в schema_version только номер последней примененной миграции находится.

Имхо, все-таки надо разделять все по модулям - это логично, удобно и поведение выглядит предсказуемо. Т.е. вводить в db:migrate параметр --module с дефолтным значением all, в scheme_version добавлять столбец module с дефолтом application и т.д.

[Fedott]

Что то я запутался. Сейчас как раз все и есть по модулям. По умолчанию применяются миграции для всех модулей. При указании только для указанного. Или я что то упустил?

[slider23]

Сорри, про db:migrate --module это я ступил, он уже есть. Я имел в виду, что стоит расширить таблицу scheme_version для удобного отображения команды db:version (плюс устранится маловероятный, но возможный конфликт миграций из разных модулей, но с одинаковым timestamp). И сделать возможным запускать db:migrate --module=application - сейчас невозможно накатить миграции только для приложения, не трогая модули.

[Fedott]

Про db:version в целом согласен что нужно сделать более информативным, но для простого отображения версии модуля в базе изменения не нужны. А делать их для избежания совпадений timestamp честно пока желания нет. db:migrate --module=application тоже сделаю.

[Fedott]

Добавил возможность запуска миграций для application. И изменил вывод команды db:version. Pull request #9