For example mission, we are going to use a JVM net utility written in Kotlin with Spring Boot as the net framework. Gradle would be the construct device; nonetheless, every little thing on this article might be achieved with Maven as effectively.
PostgreSQL is the chosen database for our instance. The commonest technique to initialize and configure the database tables is with the assistance of a migration device. For our mission, we are going to use Flyway. Nevertheless, the identical idea would work with Liquibase.
Our mission folder seems like this:
It accommodates a folder with all our database migration scripts that Flyway will use to use the modifications to our PostgreSQL database.
Moreover, our mission accommodates a Docker Compose file compose.yaml. It accommodates the definition of a PostgreSQL container, and it’s principally used to permit native growth.
After we need to begin growing domestically and creating our database, we must apply the migration both throughout the startup of our utility (which I’d not advocate if the plan is to scale the service afterward) or by hand earlier than beginning it.
We’ll add a Flyway docker container to the compose file to make our life a bit simpler. Through the compose configuration, we mount our migration script folder as a quantity and configure compose to execute the Flyway container after the PostgreSQL container has began. With this trick, we are able to routinely apply database modifications every time we run the docker-compose config.
# FILE: compose.yamlmodel: '3'
providers:
postgres:
picture: 'postgres:15'
container_name: "postgres"
setting:
- 'POSTGRES_DB=postgres'
- 'POSTGRES_PASSWORD=postgres'
- 'POSTGRES_USER=postgres'
ports:
- '5432:5432'
flyway:
# Use Docker picture containing Flyway CLI
picture: flyway/flyway:9.22.1
container_name: "flyway-migration"
# Execute migration command with enter parameters on container startup
command: -locations=filesystem:/flyway/migration -user=postgres -password=postgres -url="jdbc:postgresql://postgres:5432/postgres" -connectRetries=5 migrate
# Copy migration script folder into container
volumes:
- ./db/migration:/flyway/migration
# Anticipate Postgres container to begin
depends_on:
- postgres
Essential: Be sure the outlined ports for the PostgreSQL container within the
compose.yamlare free and never blocked by different working functions or containers. Alternatively, you may replace them to totally different ports. When doing so, be sure to additionally replace the command within the flyway service config.
With the assistance of this script, we now have a simple technique to begin up the database with all migrations utilized.
Tip: In case you are utilizing Spring Boot, you should use the module “spring-boot-docker-compose” as a growth dependency to routinely run the docker compose file when beginning your utility.
We may run the jOOQ file technology device towards this working database to create right DSL lessons. Nevertheless, the purpose is to automate this course of utterly. To attain this, we are able to improve the Gradle construct file of our mission with two extra plugins. Each or comparable plugins are additionally obtainable for Maven.
- Docker Plugin: Permits us to run docker-compose instructions on a beforehand configured file within the mission
- jOOQ Plugin: Permits us to run jOOQ file technology CLI as a Gradle process, together with all obligatory configuration.
// FILE: construct.gradle.ktplugins {
// Addtional plugins
id("nu.studer.jooq") model "8.2"
id("com.avast.gradle.docker-compose") model "0.17.5"
// ... different plugins
}
// ... different configurations
// Configure Docker plugin
dockerCompose {
useComposeFiles = listOf("compose.yaml")
projectNamePrefix = "jooq-sample"
}
// Configure jOOQ plugin
jooq {
// use jOOQ model outlined in Spring Boot
model = dependencyManagement.importedProperties["jooq.version"]
version = JooqEdition.OSS
configurations {
create("essential") { // title of the jOOQ configuration
jooqConfiguration.apply {
// configure database connection
jdbc.apply {
driver = "org.postgresql.Driver"
url = "jdbc:postgresql://localhost:5432/postgres"
consumer = "postgres"
password = "postgres"
}
generator.apply {
// Generate Kotlin lessons isntead of Java
title = "org.jooq.codegen.KotlinGenerator"
database.apply {
title = "org.jooq.meta.postgres.PostgresDatabase"
inputSchema = "public"
}
// Goal bundle of the generated code
goal.apply {
packageName = "me.jonastm.jooqsample.adapter.out.persistence.entities"
listing = "construct/generated-src/jooq/essential" // default (might be omitted)
}
technique.title = "org.jooq.codegen.DefaultGeneratorStrategy"
}
}
}
}
}
As soon as the plugins are accurately configured, we are able to mix their functionalities by making a {custom} Gradle process (I named it “generateDatabaseTypes”) that can do the next:
- Run
docker compose up. This can begin the PostgreSQL database and apply migrations - Execute jOOQ file technology
- Run
docker compose downto take away the containers once more
// FILE: construct.gradle.kt // ... earlier configurations
duties.register("generateDatabaseTypes") {
// Execute the wanted Gradle duties
dependsOn("composeUp")
dependsOn("generateJooq")
dependsOn("composeDown")
// Guarantee right execution order of the duties
duties.findByName("generateJooq")?.shouldRunAfter("composeUp")
duties.findByName("composeDown")?.shouldRunAfter("generateJooq")
}
Within the mission folder, we are able to execute this process on the command line through ./gradle generateDatabaseTypes. We’ll see {that a} construct folder can be created containing, amongst different information, the entire jOOQ lessons for our custom-tailored SQL DSL.
This makes updating jOOQ DSL class information way more handy as now we have to execute a single Gradle process. Moreover, add the execution of this process in a possible CI/CD pipeline, ensuring all required information can be found earlier than attempting to construct the appliance.
Essential: When utilizing this process in CI/CD pipeline and even domestically, ensure you have docker (with compose) working and obtainable to the present OS consumer. In any other case, the duty will fail.
If you wish to keep away from even working the Gradle process, you may go one step additional and add the duty to the default Gradle construct process. Nevertheless, this would possibly unnecessarily enhance construct occasions throughout utility growth.
// FILE: construct.gradle.kt
// ...duties.named("construct") {
dependsOn("generateDatabaseTypes")
}
This concludes my information on how one can automate jOOQ file technology. As talked about, the instance reveals how one can do it with Gradle, Kotlin, PostgreSQL, and Flyway. Nevertheless, the identical idea might be utilized to tasks with different setups, e.g., Maven, Java, MySQL, and Liquibase.
