New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added liquibase.changelogParseMode setting #3057
Conversation
…cher to better support running in IDEs
For this PR, I checked all 3 options for
(for XML had to add
|
Impact
Description
Currently, if you have a changelog with an unknown change type or precondition, liquibase just silently skips it.
For example, in
we have no
randomInvalid
type defined and so we just silently skip it and treat it as an empty changeset.If you're using an XML format which has xsd validation and you aren't using extensions, you can't have invalid changes since the XSD will catch that. But if you're using yaml/json (or dbchangelog-ext.xsd) and misspell something or are in any format and referencing an extension change and don't have that extension available you can have it skip it.
The new
liquibase.changelogParseMode
setting can be either "STRICT" or "LAX" where "STRICT" is the new default and "LAX" is the old behavior.In working through the code, the reason for the old "lax"-ness is that at the part of the parsing where we create Change objects, we don't really know what is a change and what is an attribute on the changeset, and the possible attributes are extendable so we don't know the possible attributes. So what is happening is we try to parse it as a change object and if it doesn't correspond to a defined change we set it as an attribute.
Longer term we are planning on larger changes to the parsing logic and will eventually be able to be more strict in "strict" parsing mode than we can right now and check attributes, preconditions, etc. as well. For now we can check for things that look like they are meant to be change types that don't correspond to them.
Things to be aware of
Things to worry about