Как создать БД при помощи FlyWay?

Ставь из Maven

Вот поэтому у вас в этой генте все java-приложения ставятся как dev-java/someapp-bin
а не из исходников, как завещали великие основатели генты

чем flyway отличается от liquibase?

https://www.liquibase.com/liquibase-vs-flyway

Liquibase утверждают что они круче. Верим?

Как создать БД при помощи FlyWay ?

С виду по-простому нельзя. Можно упарываться с плагинами, но зачем? Оно придумано чтобы с миграциями работать, а не базы создавать.

С виду по-простому нельзя.

Вот в видео
https://rutube.ru/video/518b843764c2bcdc3d68dd771dab4983/
человек создаёт при помощи добавления строчки
spring.flyway.baseline-on-migrate=true

Я ещё не разобрался, как это работает, но с виду база (точнее структуры внутри базы) именно создаётся.

Liquibase утверждают что они круче. Верим?

В принципе они могли бы быть круче, потому что у них модель базы имеется (создаётся,хранится,используется), а в FlyWay модели базы нет (и вряд ли FlyWay парсит SQL, чтобы такую модель построить, да и построить непросто).

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

тут у людей

   @PostConstruct
   public void migrateFlyway() {
      this.locations
         .forEach(
            location -> {
               Flyway flyway = Flyway.configure()
                  .dataSource(this.dataSource)
                  .locations(new String[]{location.getLocation()})
                  .table(location.getTableName())
                  .baselineOnMigrate(true)
                  .outOfOrder(true)
                  .load();
               flyway.migrate();
            }
         );
   }

-------------

Нанять БДшника за одну пятую часть зарплаты джависта, который вам и БД сделает, и процедур нужных напишет; и избавит вашу голову от лишних дум, и избавит ваш код от лапши с JPQL - не вариант?

)

Я ещё не разобрался, как это работает, но с виду база (точнее структуры внутри базы) именно создаётся.

Ну, применять sql-файлы он умеет. И вести историю миграций в служебной табличке

Про структуру базы при этом он толком ничего не знает, это проблема автора миграций а не flyway

чем flyway отличается от liquibase?

Обе полное говно. Потому что не умеют в миграции, написанные обычным java-кодом. И соответственно, не умеют любую нетривиальщину, не укладывающуюся в банальный SQL: например, миграции, затрагивающие несколько баз, в т.ч. разнотипных, в т.ч., например, перенос данных между SQL и NoSQL, или между базами разных сервисов при рефакторингах микросервисной архитектуры, и т.п.

https://documentation.red-gate.com/fd/tutorial-java-based-migrations-184127624.html

https://stackoverflow.com/questions/11987460/java-code-changeset-in-liquibase

Сенькс. Значит мне коллеги на работе наврали.

UPD. В таком случае я голосую за flyway: она проще, не требует спец.синтаксиса SQL-комментариев, и в ней не надо каждую миграцию руками добавлять в общий XML-реестр. (Гы, ща vbr нагуглит, что в liquibase это тоже необязательно. 🤣)

И вести историю миграций в служебной табличке

А для того, чтобы эту табличку было где хранить, база уже должна быть создана. В самом общем случае может потребоваться разрешить миграциям создавать новые базы (жава-кодом; например, для автоматического первичного шардинга единой базы), но основная база, где эта служебная табличка будет лежать, уже должна существовать.

она проще, не требует спец.синтаксиса SQL-комментариев, и в ней не надо каждую миграцию руками добавлять в общий XML-реестр

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

• голая схема в БД в 2025 году - это нонсенс, и 20 лет назад это тоже было нонсенсом: если мы делаем какой-то продукт, тягающий данные из БД, то у нас возникают определенные потребности, в частности:
  • в новой инсталляции какие-никакие данные, но требуются (хотя бы админа завести)
  • тестировщики «ожидают», что в их инсталляции, что-то да и будет заведено, чтобы не делать рутинную работу и не заводить кучу данных вручную (а иначе тратятся время и деньги на то, на что можно и не тратить в принципе)
  • если разрабатываемый продукт является условной «коробкой», то ожидается, что можно быстро сделать какой-то демо-стенд
• вот flyway с наполнением БД данными никак не дружит, постольку поскольку из pure SQL выжать ничего толком нельзя:
  • blob он лить не умеет (дрочь с base64 ограничена размером запроса SQL)
  • CSV лить оно тоже не умеет
  • не забываем, что идентификаторы в таблицах тоже должны появляться, и не везде они представлены последоввательностями
  • если данные должны лечь в несколько таблиц, что во flyway это будет откровенной болью
• идея в духе «тут в папке какой-то набор сценариев SQL, и какой-то приклад их последовательно выполняет» откидывает разработку также лет эдак на 20:
  • упорядочивание выполнения сценариев на основе конвенции названий файлов - это полный зашквар
  • переименовывать и перемещать миграции в другое место нельзя
  • если разработка находится в активной фазе, то в активном бранче постоянно лежит мусор - поскольку в СКВ не возникает конфликтов из-за модификации реестра, то оказывается, что нет какой-либо возможности понять запустится оно в итоге или нет, кроме как проверять все это руками

flyway - это больше тула для дидов, которые еще Ленина видели, хотящих условно глазами посмотреть какие там изменения будут в БД после запуска, а текущая реальность несколько иная.

А ты точно програмулька?

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

Лог чанджсетов принято хранить в отдельной схеме. А сами данные в другой схеме.

Куча текста с непонятным посылом…

И фв вроде как моложе ликви.

поскольку из pure SQL выжать ничего толком нельзя:
blob он лить не умеет (дрочь с base64 ограничена размером запроса SQL)

и не надо блобы на гигабайт+ в БД пихать. Если экономить трафик, то base64 даёт +33% к размеру. Если экономить объём хранилища, то bytea, но +100% к размеру по трафику.

CSV лить оно тоже не умеет

JSONы прекрасно и входят, и выходят. Уж из CSV вылепить JSON - едва ли большая проблема.

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

тут не знаю, что сказать. Вон у тех же людей из GitFlic в таблицах зачем-то и UUIDы генерятся, и целочисленные последовательности. Так и не доходит пока в чём прикол так делать. Но делают же. Вполне может оказаться, что из-за каких особенностей джава-библиотек и делают.

если данные должны лечь в несколько таблиц, что во flyway это будет откровенной болью

Любая накрутка поверх SQL - боль по определению. Прям вот загадка загадок - самому себе связать руки библиотеками, вместо того чтоб разговаривать с БД на языке БД - и радоваться.

-----

Вообще вот это повсеместное отношение к БД, как к «какая-то ненужная хрень, которая мешает красоте полёта мысли архитектора» - страшно бесит. У меня тут БигБосс выступал с заявлениями в духе "...и теперь куда-нибудь складываем - или в память, или в БД...". Меня сломало.

Искренне считаю, что всё совсем наоборот должно быть. БД - это отдельная ОС, и SQL - ассемблер её. И не надо мешать ваши двоичные логики джав/питонов, с троичной логикой БД. Совсем разные вещи. КМК.

вот flyway с наполнением БД данными никак не дружит

То базы не создает, то данными их не наполняет, че вы докопались-то

не совсем так: оно просто-напросто в современную разработку не умеет, мы 10 лет назад связались в этой поделкой, хорошо быстро сообразили, что нам с ней совершенно не по пути. У LB, конечно, есть проблемы, однако самая большая из них - разработчики просто не понимают насколько крутой продукт они сделали, там буквально чуть-чуть докрутить и альтернатив на рынке не будет совсем.

какая-то топорная попытка переложить вину на тех, кто совершенно не причастен. Архитекторы при построении систем смотрят на prior art, на то что сейчас есть на рынке (т.е. state of art), на перспективы довести все это до ума и какое-то разумное время сопровождать. SQL в эти категории уже не попадает (здесь разве что какие-то динозавры в виде банков и правительств остались, для которых сотня тысяч за ядро в год - это совсем не деньги), я тут, естественно говорю про системы, где 100Tb данных - это некий начальный уровень, при этом, внезапно, системы уровня «CRM цветочного магазина Ашота возле дома» уже в эту категорию попали, просто ФЗ про это не в курсе: они покупают SaaS, а что там внутри крутится - им совершенно не интересно.