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

[DAT-16377] Verify if supports method is implemented in a change to prevent unexpected behaviors #5903

Merged
merged 21 commits into from
May 22, 2024

Conversation

filipelautert
Copy link
Collaborator

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

  • Created a constant to dev environment
  • Verify if the supports method is implemented in the change if it's not part of the default liquibase changes and performs actions according to the defined action level

Things to be aware of

  • DEV will always throw exception to prevent changes being created without supports method

@filipelautert filipelautert requested a deployment to internal May 13, 2024 19:56 — with GitHub Actions Abandoned
@filipelautert filipelautert marked this pull request as ready for review May 13, 2024 21:11
//we only verify supports method if this is not part of the default liquibase changes
for (Change plugin : plugins) {
String packageName = plugin.getClass().getPackage().getName();
if (packageName.startsWith("liquibase.change") || packageName.startsWith("com.datical.liquibase.ext")) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I keep pro package here or should we verify it too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is okay to keep it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact I think you should remove it since it's an extension.

Copy link
Contributor

@StevenMassaro StevenMassaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add tests for this?

//we only verify supports method if this is not part of the default liquibase changes
for (Change plugin : plugins) {
String packageName = plugin.getClass().getPackage().getName();
if (packageName.startsWith("liquibase.change") || packageName.startsWith("com.datical.liquibase.ext")) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact I think you should remove it since it's an extension.

Controls the level of validation performed on the
supports method of Change classes. Options are
OFF, WARN, FAIL.
DEFAULT: WARN
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the default be FAIL so that we notice if we violate this rule when we run tests in all of the extensions? If we just warn, we probably won't ever actually notice until runtime, at which point it will be too late.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could change to FAIL, but this could also break existing extensions. I think we should start with WARN for 1-2 releases and then switch to FAIL - I can create a dat ticket for that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do and put it in a future sprint.

Comment on lines +147 to +149
if (packageName.startsWith("liquibase.change")) {
continue;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we even want this? Thinking more about this, don't we want all changes to be verified? If so, then I think this method just introduces another way for an extension to accidentally override the supports method and us not notice.

@suryaaki2 suryaaki2 merged commit 1a71072 into master May 22, 2024
33 of 36 checks passed
@suryaaki2 suryaaki2 deleted the DAT-16377 branch May 22, 2024 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants