Hello,
I used liquibase 2.0 and was wondering if this is the good time to get to liquibase 3.0
Unfortunately I’m using a custom extension, and the documentation is not up-to-date for this subject.
Is there a simple way for migrating my extension code to fit the 3.0 ?
Is there some documentation on how to write an extension for 3.0 ?
Thanks in advance
The extension docs is a bit light still, but it is getting higher on my stack of TODO items.
By a custom extension, do you mean a class? Or a subclass/implementation of a standard liquibase extension point? If you gave me a bit of info on your extension I can help guide you on what needs to be changed for the upgrade.
Nathan
I have both and subclass/implementation.
I managed to get around the api modifications, especially the annotations. I think this is the point where we need a little tasklist of what we should do to upgrade our extensions to the new API.
I still have a problem with a change that extends AbstractChange and uses an external file. The generateStatements method is called too early, when the file is not known and I get a NullPointerException when loading the file. IMHO the generateStatements is also called too many times, but I don’t have time to dig into liquibase code.
I found a workaround, but I’d like more information on how we can do this kind of change (using an external file)
Thanks,
With liquibase 3.0, we call generateStatements a few times in order to determine if a change is supported for a given database and to validate the parameters. That generally allows you to keep your validation and support logic in *SqlGenerator classes and not have to duplicate it.
If your particular change doesn’t work to have generateStatements called for that purpose, override the generateStatementsVolatile method to return true and make sure the supports() and warn() methods contain the correct logic since it will no longer compute that from calling generateStatemetns.
Nathan
