I am thinking about how we select the Change implementation to run from your changelog files when you have liquibase extensions installed. Currently, if you have something like this:
-
http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
LiquiBase will find the “createTable” change provided by liquibase, and will look for a “sample2” change in the classpath as well.
But what if you want to modify the behavior of createTable? Currently, if you create an extension with a “createTable” change liquibase will use the one that returns the one where the getPriority() method returns the highest value. The idea is that this setup will allow you to drop in change extensions that modify the behavior of your changelog without needing to modify the changelog at all. The example I had in my head was a drop-in replacement for which will call “set identity insert on/off” before/after inserting for sqlserver.
Any opinions on if that is a good approach? The other option that I have been thinking about is something more like what you see for custom components in Flex or WPF where you include the package name in as the namespace for tags. That way you need to change your changelog if you want a different implementation of a core change tag, but you also know exactly what is going to run. It is also too xml-ish for me, as I want to better support non-xml changelog definitions, though how you would work around the issue would need to be determined by the creators of alternate formats.
Nathan