Зачем это вообще все нужно? Все просто - необходимо хранить в репозитории историю всех изменений схемы БД, чтобы в последствии была возможность применить эти изменения к продукционной БД или, например, синхронизироваться с изменениями других разработчиков.
Как это работает:
0) Во-первых, в проекте в директории init хранятся sql дампы schema.mysql и data.mysql: схема и данные соотв-но. Эти дампы создаются/загружаются при помощи скриптов:
php mysql_dump.php
php mysql_load.php
Несколько замечаний: подразумевается, что скрипты находятся в директории cli проекта, таже подразумевается, что пользователь MySQL имеет полные права доступа на любые действия(это необходимо для создания временных БД, см. ниже)
1) В БД хранится табличка schema_info с единственным полем version. Как говорит, название, это поле представляет из себя уникальную инкрементную версию схемы БД. Это поле представляет из себя stamp, который проставляется автоматически(см.ниже)
2) В директории init/migrate проекта хранятся все миграционные sql файлы формата NNN_some_name.sql, вот NNN - это номер версии schema_info. По сути, миграционный sql - это набор alter, drop и проч. команд
Когда происходит синхронизация миграций, то из БД берется текущая версия schema_info и прогоняются все скрипты от текущей версии до последнего найденного из init/migrate. Соотв-но, если не было новых миграционных скриптов, то ничего не выполняется.
Миграция выполняется командой:
php mysql_migrate.php
После выполнения команды в schema_info вносится версия последней миграции.
Кроме этого можно выполнить тестовый прогон миграции:
php mysql_migrate.php --dry-run
В этот момент будет прогнан весь цикл миграции на временной БД, которая будет создана в начале выполнения скрипта и удалена в конце. Т.е таким образом текущая БД пользователя никак не будет затронута, что позволяет проверить на ошибки новые миграции, как свои так и чужие.
3) Как создается sql файл миграции? Можно вручную, но это скучно, поэтому существует набор скриптов, позволяющий максимально автоматизировать это дело.
Во-первых, когда вы внесли изменения в БД, стоит прогнать команду:
php mysql_diff.php
Во время ее выполнения будут показаны изменения текущей схемы БД по сравнению к той, что хранится в init + все миграции. Эти изменения будут представлены в виде набора alter, drop, create sql команд. Внимание: мы выдрали алгоритм почти "как-есть" из какого-то древнего скрипта, который нашли в интернете, и я скажу честно, выглядит он ужасно, но вроде работает, хотя порой и с мелкими огрехами
После того, как разработчик готов к тому, чтобы создать миграцию он вызывает следующий скрипт:
php mysql_create_migration.php some_name
В этот момент будет создана миграция вида NNN_some_name.sql, где NNN будет текущий time stamp. В этот же момент будет обновлена версия schema_info для текущей БД до NNN. Кроме этого, будет выполнена попытка тестового прогона миграции на временной БД которая будет создана и удалена автоматически. Тестовый прогон делается для того, чтобы обнаружить ошибки миграции как можно раньше.
Если все работает, то можно коммитить
Пример набора скриптов из одного реального проекта:
1189075049_moving_category_id_field_to_profile_table_from_shop.sql
1188825003_table_types_fixes.sql 1189427659_adding_is_approve_field_to_some_tables.sql
1188887493_adding_product_table.sql
1188890836_adding_some_core_tables.sql
1188896360_adding_extra_fields_to_profile_table.sql 1189500443_adding_product2shop_table.sql
1189597253_adding_some_fields_to_profile_table.sql
1189065170_renaming_shop_action_to_promo_action.sql
1189065605_fixing_some_fields_in_promo_action.sql 1190205157_changing_fields_that_stores_image_or_file_ids.sql
1190205613_minor_fix_in_promo_action.sql
1189068460_moving_some_relations_from_shop_to_profile.sql
