Повторяющиеся миграции Flyway - контрольная сумма не меняется, но Flyway по-прежнему выполняет сценарии - PullRequest
Новая
       5

Повторяющиеся миграции Flyway - контрольная сумма не меняется, но Flyway по-прежнему выполняет сценарии

0 голосов
/ 27 октября 2018

Я использую Flyway 4.2.0 Community Edition.Вполне возможно, что эта проблема будет решена в будущем выпуске, но наш проект обновления БД все еще не решен, и нам не повезло с получением лицензии на переход к Enterprise.

Мы успешно использовали Flyway для миграциив наших базах данных Oracle около года (11.2.0.4 и 11.2.0.2) с использованием стандартных миграций и с префиксом по умолчанию (V) и суффиксом (.sql).У нас был доморощенный подход к обработке нашего источника, но мы хотели бы перейти к повторяющимся миграциям, чтобы упростить вещи.

Ранее мы экспортировали весь наш PL / SQL в репозиторий git, используя специальные суффиксы для различных типов объектов (trigger = .trg, sequence = .prc и т. Д.).Мы хотели бы сохранить эти суффиксы, но версия, на которой мы работаем, не поддерживает более новый параметр flyway.sqlMigrationSuffixes, поэтому мы пытаемся использовать решение со списком суффиксов и циклом for.Это решение в основном работает в моем тестировании, с двумя весьма заметными исключениями: спецификациями пакетов и телами пакетов (хранятся отдельно как .pks и .pkb).

Вот скрипт, который мы используем для выполнения наших миграций (Iзнаю, что это требует работы): 

###Determine deployment environment for credential extraction
echo "Determining the deployment environment"
case "${bamboo_deploy_environment}" in 
    prod)
        path=prod
        dbs=( db1 db2 db3 )
        ;;
    stage)
        path=stage
        dbs=( db1 db2 db3 )
        ;;
    *)
        path=dev
        dbs=( db1 db2 db3 )
        ;;
esac
echo "Environment for credentials unlock is ${path}"

packages=( .sql .trg .pks .pkb .fnc .typ .java .class .properties .config .txt .dat )
echo "Packages to loop through when deploying flyway are ${packages[*]}"

echo "Databases to run against in this environment are ${dbs[*]}"
###Flyway execution stuff
for db in "${dbs[@]}"
do
    if [ -z ${db} ]; then 
    echo "No db specified"
    exit 2
    else
    echo "Working on db ${db}"
    case "${db}" in 
            db1)
                sid=db1
                host=db1.fqdn
                port=$portnm
                ;;
            db2)
                sid=db2
                host=db2.fqdn
                port=$portnm
                ;;
            db3)
                sid=db3
                host=db3.fqdn
                port=$portnm
                ;;
        esac
    fi

    echo "Current directory is `pwd`" && echo "\n Contents of current directory as `ls -l`"

    echo "Executing Flyway against ${db} for package ${pkg}"
    for pkg in "${packages[@]}"
    ###Target the specific migrations starting folder (it goes recursively)
    do
        case "${pkg}" in 
            .sql)
                loc=filesystem:${db}/migrations
                ;;
            *)
                loc=filesystem:${db}
                migrateParams="-repeatableSqlMigrationPrefix=RM -table=REPEATABLE_MIGRATIONS_HISTORY"
                ;;
        esac
        echo "Running flyway for package type ${pkg} against ${db} db with location set to ${loc}"

        baseParams="-configFile=${db}/migrations/base.conf -locations=${loc} -url=jdbc:oracle:thin:@${host}:${port}:${sid}"
        migrateParams="${migrateParams} -sqlMigrationSuffix=${pkg} ${baseParams}"
        addParams=" -ignoreMissingMigrations=True"
        flyway "repair" "${migrateParams}"
        flyway "migrate" "${migrateParams}${addParams}"
        echo "Finished with ${pkg} against ${db} db"
        unset baseParams
        unset migrateParams
        unset addParams
    done
done

echo "Finished with the migration runs"

Мой подход состоял в том, чтобы запустить развертывание в среде, экспортировать данные из таблицы REPEATABLE_MIGRATIONS_HISTORY (настраиваемая таблица для повторяющихся миграций) в качестве операторов вставки, а затем обрезать таблицуВыполните вставки и снова запустите развертывание, используя тот же артефакт развертывания.Для каждого типа файлов Flyway правильно оценивает, что контрольная сумма не изменилась, и пропускает файлы.Однако для файлов спецификации пакета (.pks) и тела пакета (.pkb) Flyway выполняет повторяемый перенос каждый раз.Я запускаю запросы для проверки, и я получаю увеличенные исполнения для всех файлов .pks и .pkb, но оставаясь на одном выполнении для каждого другого суффикса. 

select "description", "script", "checksum", count(1) 
    from FLYWAY.repeatable_migrations_history 
    group by "description", "script", "checksum"
    order by count(1) desc, "script";

У кого-нибудь еще есть идеи?Я знаю, что эти исходные файлы должны быть идемпотентными, и в основном это так, но некоторые из этих PL / SQL существуют уже более 20 лет.Мы видели несколько объектов, которые выдают ошибку при первом выполнении после компиляции перед тем, как работать идеально после этого, и мы никогда не были в состоянии отследить причину или решение.Нам нужно будет предотвратить ненужное, чтобы продвинуть это в производство.

...