Hi Lukas, hi Marshall,
answering both mails in one go, since Lukas commented on Marshall's mail
as well.
Nice to hear that 3.12 will solve some more issues. I understand that
backporting is not an option. Any idea on the general timeframe of 3.12
availability? (days, weeks, months, years... a "logarithmic" estimation
like that would be sufficient for now).
(While DDLDatabase is designed with flyway in mind, it would basically
work with liquibase scripts as well - as long as the liquibase scripts
are plain SQL scripts with comments controlling what liquibase does.
This is now my personal favorite operating mode of liquibase, no need
for XML or any of the other variants. Looking at liquibase-with-SQL
there's actually no big difference between liquibase and flyway.)
For liquibase-with-H2 in gradle there's no need for more code, this
works out of the box using the well known liquibase and jOOQ plugins. No
first hand experience with flyway and its gradle plugin, but that should
be the same. liquibase-with-PostgreSQL or alternatively
flyway-with-PostgreSQL requires some PostgreSQL database. Same with
other databases. Testcontainers only suffers from the
separate-JVM-problem, i.e. you'll end up with two separate
testcontainers if you're trying the same approach as with H2. (With H2
you cannot use a pure in-memory database for the same reason.)
The approach I went right now is as I said a variation of DDLDatabase,
using testcontainers-PostgreSQL and liquibase (flyway would be
possible), not using jOOQs DDL parser, not using H2. So basically there
is no limit. What limits with testcontainers do you mean? (other than
the one with separate JVMs which is what the DDLDatabase-variant
eliminates.)
Looking at Marshall's approach using docker-compose I see a longer
living PostgreSQL. Docker[-Compose], as usual, eliminates the installing
hassles. But the database lifecycle is manually controlled. And the
gradle scripts used by Marshall actually use a fixed port for the
PostgreSQL database, which could be problematic in Jenkins environments
where more than just one build might be running on a single machine,
rendering such a fixed port as "already in use". The testcontainers
approach maps this to an ephemeral port instead. This could maybe be
changed in the docker-compose approach, but there's more than one place
where such a dynamic port number must be injected into, and there won't
be an easy to get source for the port number either.
I'll clean up my code and post it here.
Uli
--
You received this message because you are subscribed to the Google Groups "jOOQ User
Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
