и как видите, я пофиксил так, чтобы каждая айди в xml и айди в таблице были одинаковые

и заодно почистил перед запуском билда таблицу databasechangelock

Обычно такой подход работал ВСЕГДА, но в этот раз
не сработало

как будто версионирование БД сбилось. Как теперь вернуть это в стабильное состояние ???

Я уже в диком отчаянии. А времени нет

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

Еслиyaml неправильно отформатирован, может и без ошибки запуститься

это вопрос или к чему?

Это примечание, к предыдущему сообщению.

Доктор, нога болит. Приложите подорожник к почке

Добрый день. Как можно передать переменную в аргумент макроса?

Без  ${ }.

Спасибо, сейчас попробую

@blackend Андрей

1. Да, я поменял сначала, в поле( я уже не помню под каким было id. Вроде бы под 53-м ) первичный ключ, но потом я удалил её и записи с инфой о changelog-ах с 51-го по 55-ый, чтобы откатить БД хотя бы до состояние 51-го changelog-а. из таблицы databasechangelog, а также флаг блокировки из databasechangeloglock . Надо будет поискать отдельный плагин liquidbase, который лиюо логгирует либо делает рулбэк до n-ой версии, но сейчас пока тасков море, так что придётся делать откат вручную, но КАК я хз. И тем более при удалении записей с не правильными хешами, разве не должны были удалиться сами эти хеши ??
2. мы не используем yaml( к сожалению ). Эти xml-ки для конфигурации зависимостей к спрингу меня самого бесят.

1. Удаление записей в таблице истории не откатывают изменений в бд.
2. Плагина с ролбэком не существует, для этого надо делать отдельные миграции в которых будет скрипт, делающий откат
3. На хэши может ругаться если миграция была применена, но потом изменилась, как следствие меняется ее хэш, рассчитываемый при применений миграций. Менять уже примененные миграции - моветон

1. раньше это подход РАБОТАЛ и "откат" был. Честно.
2. понял. liquidbase предоставляет такую фичу: тег <rollback>, но для этого надо будет предыдущее состояние таблицы/таблиц на зубок, что уже не удобно: какие типы, значения по умолчанию, структуру, связи, права, пятое , десятое.
3. Ок. Но а теперь что делать ? Мне нужно восстановить всё как было. А то у меня в последнее время не все подсосались ченджлоги из за чего я это удаление записи и затеял

и из databasechangelog с 51 до 55 и databasechangeloglock

1. Значит миграции брали написаны так что повторно их можно накатить и ничего не упадет, повезло
2. Это надо знать в любом случае при написании миграций, по другому никак
3. Не понял, можешь подробно ситуацию описать?

так я же всё написал выше

и ещё картинку приложил

ок. Ещё раз:
1. сначала я запуллил изменения. При этом добавились xml changelogов 54 и 55