Flyway nun Closed Source

#1

Scheint als ob die freie Version 5 von Flyway recht eingeschraenkt wurde, die Tests wurden aus den Quellen geloescht (https://github.com/flyway/flyway/commit/3387a942a5eab7eb344df7d92b19524ff99c9b29), mvn clean install funzt nicht mehr, damit faellt das Beitragen von Bugfixes/Aenderungen etc. sehr schwer, die offenen Quellen sind beschnitten (da scheint ein Pre-Prozessor eingesetzt zu werden: https://github.com/flyway/flyway/blob/master/flyway-core/src/main/java/org/flywaydb/core/Flyway.java#L1629).

Nur so als Hinweis fuer diejenigen die Flyway auch einsetzen…

#2

Projekt wurde anscheinend aufgeteilt.

[https://github.com/flyway?tab=repositories]

Die “alten” Tests scheint es aber wirklich nicht mehr zu geben.

#3

Eben.

Die oeffentlichen Sourcen sind beschnitten/unvollstaendig, Tests sind weg, Build funzt nicht mehr…

Wie sind am ueberlegen die kommerzielle Version einzusetzen oder ziu wechseln, im Moment sieht es nach letzterem aus…

#4

Habt ihr eine Alternative. Liquibase finde ich nicht ganz so optimal, da (nach meinem Stand) keine SQL-Skripte unterstützt werden.

#5

Wir sind auch auf der Suche nach Alternativen, sind aber noch nicht zu einem Ergebnis gekommen.
Liquibase hat seine eigene Abstraktion, d.h. Migrationen werden deklarativ als XML/JSON/YAML beschrieben anstatt mit SQL, persoenlich finde ich das auch etwas uebertrieben.

Mal sehen was dabei raus kommt, ist ein recht grosses System das migriert werden muesste falls wir nicht die kommerzielle Variante von Flyway bezahlen wuerden.

#6

Liquibase unterstützt custom sql scripts.

Man kann sogar eine Jar angeben und daraus eine Klasse aufrufen.

Problem bei Liquibase ist, dass es nur eine einzige Quelle hat für das Changelog.

Wenn du also Plugin based solutions hast, dann musst du das Root changelog ebtsprechend zusammenstellen. Das hat uns Wochen gekostet.

#7

Vorteil der Beschreibung per XML usw. ist das die meisten Dinge dann unabhängig davon welche konkrete Datenbank verwendet wird funktioniert. Im Detail wird es dann aber doch teilweise wieder eklig wenn ich z.B. für Oracle Varchar2 verwenden will usw.

#8

Den Nachteil, den ich mir damit ins Haus hole ist, dass das Framework die DB auch richtig unterstützen muss. Gibt es einen Bug, funktioniert es eben nicht.
Ich schreibe lieber selbst meine SQL-Skripte. Das kann ich und ich weiß, dass es funktioniert. Und zur Not kann sogar ein DBA dabei unterstützen.

#9

Autsch, unsere groessten Produkte sind ungefaehr aus 250-300 Plugins zusammengestellt… :frowning:

Wir haben nicht vor zu wechseln, und falls doch ist jedem klar dass das ein major refactoring werden wuerde…