How can I configure sql logging with the Flyway gradle plugin?

Question

I'm using the standard Flyway Gradle plugin from Flyway 3.2.1

Flyway doesn't seem to output any SQL logging, at least not at debug level.

I've configured p6spy and I can now see the SQL that Flyway is issuing, but only by enabling Gradle debug output with the "-d" switch. But when Gradle is invoked with the "-d" switch, it outputs far too much noise. This is my fallback position for now, but it's not very nice.

Ultimately, all I want to do is get the DDL that Flyway is issuing when I run the flywayMigrate output to the build log on our CI server - but I can't figure out any way to do it other than the "p6spy + enable all debug output" method outlined above.

I'm Ok with using p6spy, but I can't figure out how to configure Gradle logging for just the p6spy logger. Even just enabling all Gradle debug logging for only the flyway migrate task would also probably be Ok - it's all the Gradle bookkeeping (dependencies and whatnot) that's gumming up the logs.

So that's the question: how can I cut down on all this debug logging so I can see just the DDL that flyway is issuing.

score 1 · Answer 1 · answered Aug 11 '15 at 17:20

Assuming that you are using P6Spy with the SLF4J logger, the log messages generated by P6Spy will be at the INFO level. This means that you should be able to use the "-i" switch on the gradle build instead of "-d". This will eliminate the DEBUG messages but it will still be a bit noisy.

To leave most of the build running at LIFECYCLE level (the default), one option would be to programmatically change the log level before and after the flyway task. You might look at implementing the beforeBaseline and afterBaseline flyway callbacks to change the log level for you.

References:

score 1 · Answer 2 · answered Nov 07 '17 at 16:04

If you plan on applying the plugin and using the default tasks, I don't think you can set the log level. However, if you are okay with creating your own flyway tasks, then you can implement your own callback class.

When you extend BaseFlywayCallback, you can override several methods that hook into the flyway actions e.g. migrate, validate, info, etc.

Here's an example of how one could implement this.

build.gradle

import org.flywaydb.core.api.callback.BaseFlywayCallback
import org.flywaydb.core.Flyway

buildscript {
    repositories {
        maven { url 'https://plugins.gradle.org/m2/' }
    }
    dependencies {
        classpath 'gradle.plugin.com.boxfuse.client:flyway-release:4.2.0'
        classpath 'org.mariadb.jdbc:mariadb-java-client:2.1.2'
    }
}

class CustomFlywayCallback extends BaseFlywayCallback {

    def logger

    CustomFlywayCallback(def logger) {
        this.logger = logger
    }

    @Override
    void beforeEachMigrate(Connection connection, MigrationInfo info) {
        logger.lifecycle("Applying version $info.version")
    }
}

def getFlyway(def schemaName) {
    def flywayProps = new Properties()
    flywayProps.setProperty('flyway.url', 'jdbc://mariadb://127.0.0.1')

    def flyway = new Flyway()
    flyway.configure(flywayProps)
    flyway.setCallbacks(new CustomFlywayCallback(project.logger))

    flyway
}

task migrateSchema() {
    doLast {
        getFlyway('schema_name').migrate()
    }
}

Using this example, you can now override your own callbacks and set your own log messages using lifecycle, info, warn, etc. Check out the BaseFlywayCallback class for which methods you can override.

How can I configure sql logging with the Flyway gradle plugin?

2 Answers2