Oracle Extension: cannot use check conditions that contain "<"

Liquibase Development
1

Hi,

I use the Oracle Extensions Plugin for Liquibase but I have a problem with the “addCheck” change.
This change requires the check conditions to be defined as an xml attribute. This prevents the usage of “<” in check conditions.

I have created my own change that allows to define the check condition as xml cdata inside the addCheck element like this:

In order to do so, I needed to adjust the XMLChangeLogSAXHandler to parse the nested CDATA text. I have created a new interface “ChangeWithNestedData” analogous to the existing “ChangeWithColumns” interface to let the parser set the nested data to the change. This can be useful for others that need to create changes that interpret nested text in the xml element.
Do you want me to create a JIRA issue for this and check in my changes?

Should I merge my change with the Oracle Extension addCheck change or keep it as my separate change?

Best regards,
 Frank

2

I would think the change should be merged into the oracle extension.  I have not worked on it, so you may want to check with the authors of the extension to see what they think. 

Another option would be to use < instead of < in the attribute, but having it inside the tag as CDATA is much cleaner.

Nathan

3

Is there a way to extend the xml change log parser in an extension? I need it to parse my AbstractChange but also pass it the text that is nested in the xml element.

The way I have done it now is to add this to the liquibase parser (org.liquibase.liquibase-core/src/main/java/liquibase/parser/core/xml/XMLChangeLogSAXParser.java). But if there is a way to do it only in the extension without having to modify core liquibase this would be better.

4

There is, one goal of liquibase 2.0 is to allow custom parsers.  If you override XMLChangeLogSAXParser and specify the changelog extension that your parser will work on by overriding the getValidFileExtensions() method.  There is an issue (http://liquibase.jira.com/browse/CORE-544) to allow prioritization of custom parsers for the same extension, but that has not been implemented yet.

Nathan