Skip to content
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

Merged
merged 10 commits into from Jul 20, 2022
Merged

Conversation

nvoxland
Copy link
Contributor

Impact

  • Bug fix (non-breaking change which fixes expected existing functionality)
  • Enhancement/New feature (adds functionality without impacting existing logic)
  • Breaking change (fix or feature that would cause existing functionality to change)

Description

Currently, if you have a changelog with an unknown change type or precondition, liquibase just silently skips it.

For example, in

databaseChangeLog:
  - changeSet:
      id: 1
      author: example
      changes:
        - randomInvalid:
            tableName: person

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

  • Changes the default behavior from "LAX" to "STRICT"
  • Checks both preconditions and change
  • Applies to xml, yaml, and json. Formatted SQL can't specify changes or preconditions

Things to worry about

  • Nothing

@github-actions
Copy link

github-actions bot commented Jul 12, 2022

Unit Test Results

  4 608 files  ±  0    4 608 suites  ±0   40m 54s ⏱️ + 4m 27s
  4 592 tests +  3    4 374 ✔️  -   1     218 💤 +4  0 ±0 
54 276 runs  +36  49 264 ✔️ +32  5 012 💤 +4  0 ±0 

Results for commit df0e894. ± Comparison against base commit bcd2d53.

♻️ This comment has been updated with latest results.

@nvoxland nvoxland requested a review from suryaaki2 July 13, 2022 22:05
@FBurguer FBurguer self-assigned this Jul 19, 2022
@FBurguer
Copy link

For this PR, I checked all 3 options for --changelog-parse-mode with YAML, JSON and XML changelogs and with invalid preconditions and changes:

  1. XML
  • --changelog-parse-mode=STRICT with and invalid precondition fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid precondition continues liquibase update: PASS

  • No --changelog-parse-mod and invalid precondition behaves the same way as --changelog-parse-mode=STRICT: PASS

  • --changelog-parse-mode=STRICT with and invalid change fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid change continues liquibase update: PASS

  • No --changelog-parse-mod and invalid change behaves the same way as --changelog-parse-mode=STRICT: PASS

(for XML had to add xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" and ext: prefix to precondition and change names)

  1. JSON
  • --changelog-parse-mode=STRICT with and invalid precondition fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid precondition continues liquibase update: PASS

  • No --changelog-parse-mod and invalid precondition behaves the same way as --changelog-parse-mode=STRICT: PASS

  • --changelog-parse-mode=STRICT with and invalid change fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid change continues liquibase update: PASS

  • No --changelog-parse-mod and invalid change behaves the same way as --changelog-parse-mode=STRICT: PASS

  1. YAML
  • --changelog-parse-mode=STRICT with and invalid precondition fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid precondition continues liquibase update: PASS

  • No --changelog-parse-mod and invalid precondition behaves the same way as --changelog-parse-mode=STRICT: PASS

  • --changelog-parse-mode=STRICT with and invalid change fails liquibase update: PASS

  • --changelog-parse-mode=LAX with and invalid change continues liquibase update: PASS

  • No --changelog-parse-mod and invalid change behaves the same way as --changelog-parse-mode=STRICT: PASS

@kataggart kataggart assigned nvoxland and unassigned FBurguer Jul 20, 2022
@nvoxland nvoxland merged commit eb62560 into master Jul 20, 2022
Conditioning++ automation moved this from To Do to Done Jul 20, 2022
@nvoxland nvoxland deleted the add-changelog-parse-mode branch July 20, 2022 15:08
@kataggart kataggart added this to the NEXT milestone Jul 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

4 participants