Flyway vs Liquibase

Flyway - автор ни представлял себе что схема может быть из нескольких модулей, потому если просто захотеть данные для тестов то уже все будет плохо

Если Flyway ещё менее функциональна чем Liquibase, тогда точно Liquibase (Flyway не пробовал).

Liquibase оно уже научилось plain sql?

да, нужно просто зафигачить тэг sql. Откатить его оно конечно не сможет.

а модульность там есть (т.е. куча sql скриптов гадящих в одну схему)?

юзал только liquibase, мне нравится. Оно работает.

А когда оно его не умело?

<changeSet author="troll" id="20150609-01">
        <comment>Add column</comment>
        <sql>
            alter table tbl.transfer_container add column uid varchar(22);
        </sql>
        <rollback>
            alter table tbl.transfer_container drop column uid;
        </rollback>
</changeSet>

где xml в plain sql ?

ты можешь импортить один скрипт в другой (тэг include). Это достаточная модульность?

если хочется нафигачить каких-то хитрых приблуд, то огромная фича в том, что все «скрипты» - это стандартный XML. Чо хочешь, то и делай с ними, хоть по аннотациям скрипты генери. Но мне было не нужно.

не понимаю, что ты хотел бы видеть, напиши пример?

Уже давно можно без xml.

Liquibase

Не сказать что без нареканий, но работает и убрал много головной боли.

Flyway

Не тыкал

вот это и смущает. мало кто тыкал.
imho flyway кажется проще и имеет нативный сапорт для gradle в отличие от liquibase тыц!

to subwoofer
если просто захотеть данные для тестов то уже все будет плохо

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

если у тебя юнит тесты то это норм, если интеграционные то гиморно

и если большое приложение с разными модулями - то без всяких тестов тоже будет облом

Ну т.к. я не знаю никаких разумных причин юзать грабли, то для меня это не актуально.

юзал только liquibase, мне нравится. Оно работает.

удобно ли? меня пугают излишки xml и то что чуваки запили платный продукт с enterprise support - т.е. порезали бесплатный

поясни плиз. не совсем понял про грабли

gradle часто зовут граблями, небезосновательно

спасибо, первый раз слышу

gradle

Я бы не сказал что его способ разруливать зависимости в принципе лучше чем в мавене, возможно для каких то проектов так и есть. Формат записи конфигов вообще вторичен.

cast subwoofer, asaw, stevejobs, ya-betmen

такой вопрос, вы не пробовали настраивать авто откатывание версий?
например есть 2 ветки релизов:
1. version_1 - db version - 4
2. version_2 - db version - 15
я сейчас на например на version_2. чекиню из гита version_1, собираю - и оно само определяет что миграций например 4 есть, а версия базы 15. и откатывает до 4й. при переходе на version_2 все наоборот (что как я понимаю не проблема).
если пробовали, то насколько трудно наточить такую штуку? есть ли что-то похожее из коробки?

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

на продакшене зачастую даже накатывать новую нельзя автоматически, а на девелопе проще все снести и накатить последовательно заново (или если тормозит то снять дамп базы и накатывать его)

ок, спасибо парни. вы мне реально помогли.

Он абсолютно хуже. по крайней мере до версии 2.10. Новее не юзал.

Что это у вас за юнит-тесты, которые в базу пишут?

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

Я немного соврал, пишут в базу интеграционные.
Юнит просто мокают то что нужно

нет, не пробовал. Я просто каждый раз разворачиваю с нуля базу (автоматически, скриптом), прогоняя все ченжесты, начиная с первого

в том числе и в автотестах - поднимаю hsqldb и накатываю ликвибейзом все сколько есть

Flyway не рекомендую. Хеши файлов миграции платформо зависимые. На винде хеш не такой как на unix (скорее всего изза переносов строк) в итоге если в команде есть те кто сидит на Linux/Mac и те, кто на Windows, то последние будут страдать тем, что обычный дамп базы без гемора не смогут заюзать, также конект к ремоут базе может быть проблемным для них.

Liquibase намного приятнее в работе.

В liquibase, кстати, та же проблема с хешами из-за <sql>.

его способ разруливать зависимости в принципе лучше чем в мавене

Лучше, можно заовверайдить на общем уровне любую зависимость на любую. В результате больше никакой ебли с лишними логгерами из транзитивных зависимостей.

Я юзал flyway и liquibase немного. flyway сильно проще, но SQL-only.

И как часто такое извращение было нужно на практике?

хреново.
мы как раз все на винде и базу разворачиваем обычно с линукс серваков.
и писать миграции мы будет как раз на sql

Форсируйте тогда переводы строк на LF-only. Вы же только собираетесь миграции делать.

Мне - почти на каждом проекте. Если человек пять одновременно срут в зависимости относительно большого Spring MVC проекта, потом ловишь ошибки, почему логи не туда пишутся.

Я бы попытался понять почему в после пары месяцев зависимости до сих пор активно изменяются. При таком подходе сами зависимости это наименьшая из проблем.

Потому, что фичи постоянно пилятся.

Видимо этот проект это универсальная либа, которая умеет делать всё.

Любой инф. система для государственного заказчика в такую херню в итоге вырождается.