Liquibase ideas

Ideas
#1

Hi,

I would like to generate liquibase changelog with data, it would be nice to have it in the studio action (or as an action in the app ?).
By exemple, I want launch the application and configure some filters, or reports, or simply create some init data for my app with my screens more easily that do it manually in the liquibase changelog.

I think it would be nice to have a regenerate “snapshots” changelogs.
During development, we generate some changelog, but we have to clean it in some occasion (by exemple before commit), so, wi remove auto generated changelog (in the Project tab), we recreate database (Jmix tab), then we generate liquibase changelog (Jmix tab), and in some case we want to rename and move it in the root changelog folder (Projet tab)

And a last one, when studio execute liquibase we have a trace in the Run panel

/Library/Java/JavaVirtualMachines/liberica-17.0.5/bin/java liquibase.integration.commandline.Main --driver org.hsqldb.jdbc.JDBCDriver --changeLogFile com/compnay/addon/commons/liquibase/changelog.xml --url jdbc:hsqldb:file:/path/to/addon-commons/.jmix/hsqldb/com;shutdown=true --username sa --logLevel INFO update

In my case, it’s not suffisant to replay manually in a terminal and solve myself my first demand (a missing classpath pb), maybe if all the infos were present, or if the liquibase gradle plugin was set, the dev would be free to adapt his processus

#2

Another need is about test and liquibase

Jmix detect entity create in test folder, that’s great, but liquibase don’t propose to generate changelog in test ressources for them, I need to move my entity in main, generate changelog, then move entity and changelog in test

#4

Hi Benoit,

I agree that it would be convenient, but it’s quite hard to implement in a generic way.

Do you mean a standard action in Studio which would do all this automatically?

It’s quite easy to configure the Gradle Liquibase plugin in the project:

plugins {
        // ...
    id 'org.liquibase.gradle' version '2.2.0'
}

dependencies {
    // ... 
    liquibaseRuntime 'info.picocli:picocli:4.6.1'
    liquibaseRuntime sourceSets.main.output
}

configurations.liquibaseRuntime.extendsFrom configurations.runtimeClasspath

liquibase {
    activities {
        main {
            changelogFile 'src/main/resources/com/company/app/liquibase/changelog.xml'
            url 'jdbc:postgresql://localhost/mydb'
            username 'root'
            password 'root'
            logLevel 'info'
        }
    }
}

I’m not sure Studio should to pre-configure it in every project. Perhaps we’ll include this in documentation.

We’ll take it into account when working on this epic: https://youtrack.jmix.io/issue/JST-177/Support-content-in-test-roots

Regards,
Konstantin

#5

I understand, I created a screen dedicated to UAT, maybe that’s the best way for me

@UiController("com_TestScreen")
@UiDescriptor("test-screen.xml")
class TestScreen : Screen() {
    @Autowired
    lateinit var testDataLoader: TestDataLoader

    @Autowired
    lateinit var springLiquibase: SpringLiquibase


    @Subscribe("loadTestDataBtn")
    private fun onLoadTestDataBtnClick(@SuppressWarnings("kotlin:S1172") event: Button.ClickEvent) {
        testDataLoader.load()
    }

    @Subscribe("resetDatabaseBtn")
    private fun onResetDatabaseBtnClick(@SuppressWarnings("kotlin:S1172") event: Button.ClickEvent) {
        springLiquibase.isDropFirst = true
        springLiquibase.afterPropertiesSet()
    }

    @Subscribe("generateDataChangelogBtn")
    private fun onGenerateDataChangelogBtn(@SuppressWarnings("kotlin:S1172") event: Button.ClickEvent) {
        // TODO
    }
}

Yes, a studio action on the datastore, maybe below the “Generate Liquibase Changelog”

Thanks, I will try that

#6

Do you think this action should operate only with uncommitted changelogs? Because otherwise it would be very dangerous, right?

#7

Obviously that’s will be really safe to only merge uncommitted changelog, but I’m not sure that will be pertinent !

If you use feature branches, the changelog merge is ok until you merge your branch.
In my case, the CI will refuse auto dated changelog in the job “release to prod”. So it will be always ok to merge them because auto dated changelog are only in local or test env, never in production.

So I’m not sure that Jmix studio should have limit on this function, or maybe with an option to deactivate the limit.

#8

Created issue, we’ll consider this feature in the future.