>Да, при наличии двух и более файлов с одной версией он ругается. Но как часто Вы меняете базу, что не можете угнаться за версиями?

в активной фазе разработки проекта база меняется очень часто. потом пилятся фичи, зачастую параллельно, в итоге - будут конфликты. У нас в основном проекте наваяли самописную подсистему управления миграций, там сделали тупо цифровой номер файла - постоянно конфликты лезут. Но там я хоть при комите вижу этот конфликт и поднимаю версию своего файла до нужной, иначе комит просто не пройдет. В случае же с flyway получается вполне можно закомитить 2 файла с одной версией (но разными именами файлов, т.е. комит пройдет) и проблемы вылезут уже позже... не очень хорошо. можно конечно хуками обвешаться, но это всё равно костыль.

> Поэтому я и говорю о downgrad'е, что если необходимо внести изменения в миграцию, можно было ее downgrade'нуть изменить и upgrade'нуть измененную.

и как ты предлагаешь в таком случае отслеживать изменения миграций? хеш-суммы файлов в базе хранить рядом с версией (и не одну а 3, на случай коллизий)? не, уж лучше так - каждый набор изменений в отдельном файле со своим набором sql операторов. Иначе потом придется по всем миграциям бегать смотреть, кто тебе дев-базу сломал (точнее, лезть в историю VCS), в текущем же варианте - посмотреть нужно будет только последние несколько файлов никуда не переключаясь.

> А так получается, что при дальнейших изменениях, которые можно было бы объединить в один файл, приходится плодить маленькие миграции, тем самым увеличивая номер версии типи V1_2_45.

поэтому я и говорю - решение с номером версии жутко спорное. как по мне гораздо лучше таймстамп и краткое описание в имени файла. количество файлов миграций по большому счету ни на что не влияет.

> Считаю, что если программа взялась работать с версионностью БД, то нужно это делать намного продуманней. С pure SQL, мне кажется, решается, если ограничить запросы только касающиеся структуры БД, и хранением для каждой миграции состояние структуры изменяемых таблиц.

Смотри, нужно для каждого запроса писать "обратный" запрос, который вернет базу в предыдущее состояние. Автоматически такие запросы написать ИМХО невозможно. А пользователи библиотеки такое делать ручками никогда сами не будут. Это решается только своим псевдо-языком миграций, но возникает проблема поддержки всех фич СУБД. Как я понимаю, тут поддерживаются разные СУБД, и нужно следить за изменениями в каждой... Так себе задачка.

И куда девать запросы на изменения данных? Вот нужно заказчику по хитрому условию обновить какое-то поле в большой таблице. Все, эту миграцию мы уже откатить не сможем, т.к. хранить в миграции состояние всех дев/превью/прод баз никто в здравом уме не будет. И разбираться потом, какие миграции откатываются а какие нет - тоже лишний гемор. Гораздо проще добавить новую миграцию.