Вопрос или проблема
У нас есть долгая история скриптов миграции V incremental, некоторые скрипты содержали несколько ошибок и теперь трудно читать полную схему таблицы базы данных.
Названия от 1-го до последнего:
V1_0_0__newdb.sql ... V1_0_27_1__tablex.sql
Если мы хотим ввести новый базовый скрипт, какое имя файла следует использовать?
- должен использоваться
B1_0_27_1__newdb.sql - или можно использовать
B2_0_0__newdb.sqlи продолжить с новыми V incremental? - новый базовый скрипт представляет все изменения от 1-го до скрипта 1_0_27_1.
Это оставляет пропуск в нумерации, следующий файл будет скрипт V2_0_1__changex.sql.
это нормально для старых установок и тех, которые были созданы из нового базового скрипта?
ps: Одна из проблем с SQL заключалась в использовании внутренних разделителей переменных flyway ${ / } в SQL формулах, предназначенных для использования как подстроки. Insert Into tableN (id,name,value) Values(1, 'key1', 'value ${env1} constant')
(flyway=инструмент миграции SQL)
Ответ или решение
Вопрос о наименовании скриптов в Flyway, особенно когда речь идет о версиях (V) и базовых (B) скриптах, является ключевым для поддержки целостности базы данных. Правильная Конвенция по наименованию помогает не только систематизировать миграции, но и предотвращает потенциальные проблемы с совместимостью.
Конвенция наименования для Flyway: V и B скрипты
-
Существующая схема наименования: У вас уже есть набор V-скриптов, начиная с
V1_0_0__newdb.sqlи заканчиваяV1_0_27_1__tablex.sql. Это указывает на последовательные миграции, которые вносят изменения в структуру базы данных. -
Необходимость базового скрипта (B): Вы намерены ввести базовый скрипт, который представляет все изменения, произошедшие с первых версий до последней (т.е. до
V1_0_27_1). Это создаст легкую возможность для миграции старых баз данных к новой структуре.
Варианты наименования базового скрипта
-
Использование B1: Если вы используете файл с именем
B1_0_27_1__newdb.sql, это будет правильно с точки зрения последовательности, так как этот скрипт включает все изменения вплоть доV1_0_27_1. Такой подход будет понятен и старым пользователям, так как не вносит путаницу в существующую схему наименования. -
Использование B2: Альтернативный вариант — начать новый отсчет с
B2_0_0__newdb.sql. Такой подход также возможен, но с ним возникают определенные риски. Во-первых, это создаст пробел в нумерации, который может привести к путанице. Поскольку следующий скрипт будетV2_0_1__changex.sql, может возникнуть недопонимание о том, каким образом между скриптами B и V произошли изменения.
Совместимость с существующими установками
При условии, что вы создаете новую базу, начиная с B1_0_27_1, старые установки смогут продолжать функционировать без изменений. С другой стороны, если вы начнете с B2, вам нужно будет четко документировать изменения и обеспечить, чтобы все старые версии могли корректно перейти на новую схему. Следовательно, использование B1_0_27_1 для базового скрипта будет предпочтительным для большей ясности и меньшего количества возможных ошибок.
Прочие соображения
Учитывайте, что ранее находили ошибки в SQL-сценариях, такие как использование переменных ${/} в строках, которые не должны заменяться. Это подчеркивает необходимость тщательного тестирования любых новых миграций для избежания новых проблем, которые могут возникнуть в процессе работы с базами данных.
Заключение
С точки зрения схемы именования, лучшим вариантом будет использование B1_0_27_1__newdb.sql. Это не только поддержит вашу текущую структуру миграций, но и позволит сохранить совместимость со старыми версиями. Создание B2_0_0__newdb.sql, хоть и возможно, может привести к ненужной путанице и проблемам с идентификацией миграций.