Home > Software engineering >  Execute JOOQ query in between Flyway migration and Hibernate schema validation
Execute JOOQ query in between Flyway migration and Hibernate schema validation

Time:12-23

My spring-boot application uses Flyway for handling database migrations and Hibernate as ORM. On top of that, I'd like to use JOOQ to create database views programatically with JOOQ's DSL to achieve compile-time safety. First, I'd like my Flyway migrations to complete. Then I want to run my JOOQ statement to create database views. And as a last step I'd like to run the Hibernate validation to confirm that the entities are matching the actual database schema.

However, I'm struggling with running my code at the right time. I've tried to run the JOOQ statements implemented as Flyway callbacks after migration, but that seems impossible since DSLContext bean has a dependency on Flyway bean and I'm getting an error on application startup. I've looked for any hook to execute my code before Hibernate's schema validation, but unfortunately couldn't find anything.

Is there any way to execute custom JOOQ code using DSLContext bean after Flyway migration and before Hibernate's schema validation?

CodePudding user response:

Up to this point I was trying to inject DSLContext as a bean into my callback classes - and as mentioned in the original question, this is impossible because of the dependency towards Flyway bean which is not completely initialised at the moment of callback creation:

@Component
class ViewInit(private val dsl: DSLContext) : Callback {
  override fun handle(event: Event, context: Context) {
    // FIXME: won't work as DSLContext bean is not fully initialised at this point
    // dsl.createView([...])
  }
}

However, Flyway's Callback#handle method signature provides a Context parameter that can be used to create a local DSLContext reusing the database connection obtained by Flyway.

class ViewInit : Callback {
  override fun handle(event: Event, context: Context) {
    val dsl = DSL.using(context.connection)
    // dsl.createView([...])
  }
}

With that setup everything runs in proper order and as expected.

An alternative solution would be to implement Flyway's repeatable migration as a class extending BaseJavaMigration:

class R__V0_001_CreateView : BaseJavaMigration() {
  override fun migrate(context: Context) {
    val dsl = DSL.using(context.connection)
    // dsl.createView([...])
  }
}
  • Related