но вот реализацию в самой flyway нужно допилить

с таким форматом порядок накатывания будет зависеть от номера таски - здесь соглашусь с Александром, лучше разнести версию и таску

почему ошибка падает - без самой ошибки это гадание на кофейной гуще
но раз 1124 накатился, проблема точно не в формате, при условии что у 1125 формат аналогичен

именно по этой причине мне больше нравится liquibase.
использую в нем исключительно SQL-миграции, игнорируя кросс-платформенный XML.
зато порядок применения миграций никак не зависит от именования файлов. порядок применения миграций задается ЯВНО порядком следования ченджсетов в теле файла. такая организация гораздо дружественней при слиянии веток.

flyway всем хорош, но эта его идеология с определением порядка миграций по номеру в имени файла - не самое лучшее решение. ну и ролбеков нет в бесплатной версии.

Правильно понимаю, что решения нет?

Я не знаю ответа на данный вопрос.

https://flywaydb.org/documentation/concepts/migrations#naming

вот тут написано, какие части имени файла configurable. Версии среди них вроде как нет.

Так не всегда будет работать ибо новые миграции могут ломать друг друга не учитывая изменения в другой

да уж, понятно. Спасибо коллеги

Да, ликвибейз хорош, плюсую. Главное использовать при написании базы исключительно стандартный SQL без мелких фишек БД. Тогда мигрировать можно будет хоть на оракло, хоть на H2 тестовые базы поднимать.

Только вот генерацию UUID как дефолтного значения, например, все равно будет зависимой от типа бд, так что не всегда получается совсем уж без проблем мигрировать.
Хотя, если делать через XML, то генерацию UUID можно сделать через специальный property

Больная тема на самом деле, но всё решаемо. Вдруг у тебя однокнопочная система на SpringData которая там уж как нибудь сама)

На самом деле столкнулся с этим, только когда перевели на Spring Data JDBC (я и не знал, что JPA генерит UUID сама, а не использует средства бд)

Ребят, а почему Stream нетипизированного Set'а даже после .map(Object::toString) или .map(String.class::cast) остаётся Stream'ом Object'ов, а не String'ов?
Что с этим можно сделать, чтобы не кастить лямбда-параметр каждый раз?

Я правильно понимаю, что service layer лежит между контроллером и репозиторием?

А если Set скастить к Set<Object>?

Приглашаем Java разработчиков (Strong Junior, Middle, Senior ) (Москва, 5/2 в офисе на Павелецкой) для разработки бэкэнда распределенной масштабируемой платформы мониторинга. Высокие нагрузки, параллельная обработка, bigdata, вобщем все что мы любим ))), стек очень интересный - Cassandra, Kafka, Storm, Spring, Spark, PostgreSQL, etc ))) от 150 000 р, Senior's от 220 000 р, белая, 13, проектные, ТК, ДМС. Фидбеки - в личку.

ну лямбда же анонимная функция, по сути сет нетипизирован, потому и функция нетипизированная заходит, и соответственно из вот такого
<R> Stream<R> map(Function<? super T, ? extends R> mapper);
становится такое
Stream map(Function mapper);

то есть что не возвращай функцией будет Object

При НЕОБХОДИМОСТИ, если логики интерфейса репозитория не хватает для реализации требований (ответ академический - ДА)

Понятно.
А как получше лечить?

Вот товарищ выше предложил сразу скастить в Set<Object> - это прокатывает - @kuzznya, спасибо.
Но, конечно, с warning'ом.