customize databaseChangeLogTableName

[ykotik]

Dear All,

i would like to customize the following params ;

-Dliquibase.databaseChangeLogTableName=VE_DATABASECHANGELOG ^
-Dliquibase.databaseChangeLogLockTableName=VE_DATABASECHANGELOGLOCK

how to that with this plugin ?

Best regards,
Yuri

[stevesaliman]

You should be able to simply pass these options to the Gradle command line. For example,
gradle -Dliquibase.databaseChangeLogTableName=VE_DATABASECHANGELOG -Dliquibase.databaseChangeLogLockTableName=VE_DATABASECHANGELOGLOCK update runs the update task with the tables you specify.

You could also put them in build.gradle with the following:

System.setProperty('liquibase.databaseChangeLogTableName', 'VE_DATABASECHANGELOG')
System.setProperty('liquibase.databaseChangeLogLockTableName', 'VE_DATABASECHANGELOGLOCK')

These lines should not be inside any other blocks. I tested it by putting them just before the liquibase block to make it easy to find.

[ykotik]

hi Steve,
i know this option to do that via system properties. The problem is that i would like to have single gradle scripts that works with multiple dbs and different liquibase service tables.

And system properties look like a workaround for this task.

Thanks ,
Yuri

[hallatech]

Yuri,
Don't know if this helps your use-case but we also have multiple schemas driven from a single gradle script.
This has nothing to do with changing the name of the changelog tables as each schema has its own set. We don't have a need to fiddle with its name.
As a basic example something like this
project.ext.liquibaseSchemas=['core':'liverw','cata':'livea','catb':'liveb',......] //just using a map for convenience
liquibase {
activities {
liquibaseSchemas.each { schema, defaultSchema->
"${schema}" {
.... //here add the schema specific configuration
username dbconfig.profile.getAt(defaultSchema).username
password dbconfig.profile.getAt(defaultSchema).password
classpath "${customLiquibaseClasses}"
logLevel project.ext.logLevel
contexts project.ext.contexts
...
}
}
runList project.ext.runList
}

Then we have various wrapper tasks that can be called individually to update a single schema such as:
task updateCore (type: GradleBuild) {
description "Wrapper for setup and Liquibase core schema updates."
group liquibaseCustomTaskGroup
propagateStartParameter(startParameter)
tasks = [
'createCoreDataSourceServer', //custom pre-requisite task
'createJDBCModule', //custom pre-requisite task
'update'
]
startParameter.projectProperties.putAt('runList', 'core')
project.logger.debug "Task updateCore configured parameters: ${startParameter}"
}

This may be totally irrelevant to you but what is the use case for having to use different names for the changelog tables ?

[ykotik]

hi Steve,
i know it works with multiple schemas , we have only one schema.

The use use is microservices architecture with idea to have "independent components" with their own list of tables. and each of them has its own liquibase scripts it cares about. To make prevent access from one microservice to the tables from other is not quite possible so we have the rule: who writes in tables own them and other microservices can read from tables of another microservice.
That is the cause why we tables of all microservices in one schema.
Probably the architecture can be done other way but we already went this way and that is the reason why look for the requested feature.

[stevesaliman]

Liquibase itself uses a system property to override the database change log table, so any solution we come up with will ultimately wind up setting a system property. I'm thinking that if we can do this with the things Gradle already has built in, we can keep the plugin simple.

What if you did something like this:

System.setProperty('liquibase.databaseChangeLogTableName', ext.changeLogTable)
System.setProperty('liquibase.databaseChangeLogLockTableName', ext.changeLogLockTable)

You could then set the changeLogTable and changeLogLockTable properties using standard Gradle property mechanisms. I'm not sure how your microservice projects are set up, but if you had a master build.gradle file, and each microservice was in a sub project, you could set the needed properties in each microservice's gradle.properties file.

And, since I can't pass up a shameless self promotion opportunity, I'll mention my Gradle Properties Plugin which gives you more options in how you set properties.