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
[CN-983] Persistence of SQL metadata shouldn't be changed once it was enabled #883
Conversation
@@ -386,6 +387,12 @@ func (v *hazelcastValidator) validateNotUpdatableHzPersistenceFields(current, la | |||
} | |||
} | |||
|
|||
func (v *hazelcastValidator) validateNotUpdatableSQLFields(current, last *SQL) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest using simpler name like: validateSQLFields
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the convention we use in the validation.
e.g:
- validateNotUpdatableHzPersistenceFields
- validateNotUpdatableHazelcastFields
hz.Spec.SQL.CatalogPersistenceEnabled = false | ||
err := k8sClient.Update(context.Background(), hz) | ||
Expect(err).Should(MatchError(ContainSubstring("field cannot be disabled after it has been enabled"))) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think we need to check for exact match of error message. I dont think we do it in other tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? Ideally we should do it other tests too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dzeromski-hazelcast we do it in other tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue that putting such a specific check in test is unnecessary and makes maintaining tests harder in the long run. But up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would disagree. Errors are part of the public API, so in this case, we make sure to test the public API and not have a false-positive test, in case we get the err
but is not related to the validation
Test Results
Failed Tests
|
Description
The configuration for persistence of SQL metadata shouldn't be changed once it was enabled