Создание таблиц Liquibase ChangeLog и LogLock на более поздней стадии без сбоя уже выполненных сценариев - PullRequest
Новая
       13

Создание таблиц Liquibase ChangeLog и LogLock на более поздней стадии без сбоя уже выполненных сценариев

1 голос
/ 22 апреля 2020

У меня есть одна микро-служба , работающая с давних времен, однако несколько дней назад мы поняли, что были определены таблицы custom changelog и changeloglock неправильно . См. Ниже ... 

spring:
    liquibase:
        abc:
            change-log: classpath:/liquibase/changelog.yml
            database-change-log-table: CUSTOM_CHANGE_LOG
            database-change-log-lock-table: CUSTOM_CHANGE_LOG_LOCK

abc добавлено между правильным путем, и мы уже почти 18 сценариев уже выполнены, которые уже зарегистрированы в основных таблицах DATABASECHANGELOG и DATABASECHANGELOGLOCK.

Так что, если я исправлю путь в yml согласно приведенному ниже 

spring:
    liquibase:
        change-log: classpath:/liquibase/changelog.yml
        database-change-log-table: CUSTOM_CHANGE_LOG
        database-change-log-lock-table: CUSTOM_CHANGE_LOG_LOCK

, тогда go включится и выполнит все старые 18 сценариев, что приведет к отказ. Как решить эту проблему?

Кроме того, я не уверен, будет ли она создавать пользовательские таблицы автоматически или мне нужно создавать их вручную?

Любая помощь для both the points будет оценена. комментарий, если вам нужна дополнительная информация

Ответы [ 2 ]

1 голос
/ 22 апреля 2020

Если я правильно понимаю ваш вопрос, есть два варианта:

  1. Напишите preConditions в существующие наборы изменений и укажите атрибут onFail = "MARK_RAN". Таким образом, все ваши наборы изменений потерпят неудачу на preConditions и будут помечены как RAN в таблице CUSTOM_CHANGE_LOG. Ваша заявка будет успешно запущена.

  2. Укажите CUSTOM_CHANGE_LOG таблицу и скопируйте все данные из databasechangelog.

ChangeSet для копирования данных из таблица в таблицу может выглядеть так: 

<changeSet id="foo" author="bar">
    <preConditions onFail="MARK_RAN">
        <tableExists tableName="databasechangelog"/>
        <tableExists tableName="CUSTOM_CHANGE_LOG"/>
        <sqlCheck expecterResult="0">
            SELECT COUNT(*) FROM databasechangelog; 
        </sqlCheck>
    </preConditions>
    <sql>
        INSERT INTO CUSTOM_CHANGE_LOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, EXECTYPE, MD5SUM, DESCRIPTION, COMMENTS, TAG, LIQUIBASE, CONTEXTS, LABELS, DEPLOYMENT_ID)
        SELECT ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, EXECTYPE, MD5SUM, DESCRIPTION, COMMENTS, TAG, LIQUIBASE, CONTEXTS, LABELS, DEPLOYMENT_ID
        FROM databasechangelog
    </sql>
</changeSet>

Этот набор изменений должен выполняться первым при запуске приложения. Поэтому вы должны поместить этот набор изменений перед всеми другими наборами изменений в вашем списке изменений. После копирования всех данных liquibase должен обработать все ваши существующие наборы изменений так, как будто они уже выполнены.

Я бы использовал опцию № 1, поскольку ваши наборы изменений в любом случае должны иметь предварительные условия.

0 голосов
/ 23 апреля 2020

Эта проблема решена. Есть 2 способа сделать это без запуска любого ручного скрипта. Но я предпочел ниже одного

. Мы не будем вводить пользовательские таблицы в application.yml, но добавим новый запрос в журнал изменений.

changeset будет выглядеть примерно так 

- changeSet:
      id: your-id-here
      author: kunal-vohra
      #dbms: oracle #if you want it to run db specific then uncomment
      changes:
        - sqlFile:
            encoding: utf8
            path: ./liquibase/changes/sql-file-name.sql

И sql-file-name.sql будет выглядеть примерно так: 

declare
begin
  execute immediate 'CREATE TABLE CUSTOM_CHANGE_LOG AS SELECT * FROM DATABASECHANGELOG WHERE AUTHOR = ''kunal-vohra''';
  exception when others then
    if SQLCODE = -955 then null; else raise; end if;
    UPDATE CUSTOM_CHANGE_LOG  SET MD5SUM = null;
end;
/

То, что происходит в приведенном выше запросе, если таблица уже создана, то она не будет создавать в противном случае это будет новая таблица.

И тогда будет отброшено все **HASH**.

Затем поднимите 2-й PR с изменением application.yml

spring:
    liquibase:
        change-log: classpath:/liquibase/changelog.yml
        database-change-log-table: CUSTOM_CHANGE_LOG
        database-change-log-lock-table: CUSTOM_CHANGE_LOG_LOCK

Основное преимущество, которое мы имеем здесь, заключается в том, что нам не нужно ничего запускать вручную на PROD.

Если вы хотите сделать вышеупомянутое в одном PR , другой способ - , просто переместите changeset в начало файла вместо ниже.

...