-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Reverted commit 54a5f938f99 because of Bug #23174 #23507
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
Reverted commit 54a5f938f99 because of Bug #23174 #23507
Conversation
|
Yes need to fix flow instead @blizzz |
|
@nickvergessen @blizzz I've reverted the revert and fixed the migration instead. Since I assume that the column 'entity' should never become Null when added, I've changed 'notnull' to FALSE instead of removing the empty default value. Is this a valid fix for the problem? A comment on the original test: would it not be better to differentiate between NotNull and NotBlank? |
|
Well empty strings are saved as Null in Oracle, so having an NotNull with default |
|
Well, that's bad. While MariaDB obviously accepts adding "not null" columns without explicit default, SQLite does not: Mariadb: SQLite: |
blizzz
left a comment
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.
@Cybso could you squash the commits, please?
|
@blizzz I'm still not very familiar with the extended git features. I've used "git rebase -i HEAD~2" to squash the second commit with the first one, but when I try to push this to Github, I get the following error: Can you give me I hint how to fix this? |
You need |
2fd97ac to
2a376d4
Compare
| if(!$table->hasColumn('entity')) { | ||
| $table->addColumn('entity', Type::STRING, [ | ||
| 'notnull' => true, | ||
| 'notnull' => false, |
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.
We need a follow up migration which fixes existing instances?
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 think it would be nice to have matching database definition across all instances, but not exactly required. The module won't write any NULL values into this column, so at least for MySQL and SQLite it doesn't matter if it's true or false (cannot speak for Oracle). An alternative implementation would be to add a second call which updates the database definition to "NotNull = true" and removes the default value after the table has been extended.
@blizzz, what's your opinion?
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.
Consistency and an expected state is to be preferred, otherwise we indeed may run into trouble in future changes. So, yes, a migration step would be ideal to add.
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.
Sorry, I've tried, but at the moment I do not find the time to implement this second migration. Can someone take over?
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 will
|
Done in #23882 |
Reverted commit 54a5f93 from @nickvergessen to fix bug #23174 which breaks upgrades to 18.0.10.
Maybe it would be better to fix the migration of oc_flow_operations instead, but I'm not familiar with this part of the code.
fix #23174