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
Add explicit renameColumn method (4.x) #6280
base: 4.1.x
Are you sure you want to change the base?
Conversation
3800200
to
86baabb
Compare
return ''; | ||
} | ||
|
||
if (! empty($column['version'])) { | ||
if ((string) $column['type'] !== 'DateTime') { |
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.
This might not be covered by tests, when I messed around and removed the if
there was an error that Dbal/Types/DateTimeType cannot be converted to string, which makes sense because 'type' in column is a DbalType
which doesn't have a __toString()
, might need to be backported to 3.8 as well
I also think in 4.x we should abolish column converted to arrays in all the AbstractPlatform methods and use the Column
class to get the correct type hints and static analysis (for a different PR)
Since we've reverted the feature, this is technically not a merge anymore. I've adjusted the PR title accordingly. Can you please rebase your changes onto 4.0.x? Currently the PR contains irrelevant changes that 4.0.x contains already. |
cde8651
to
5678b6d
Compare
Hmmm, 4.0.x was released already? I though you would wait for this PR on both 3.9 and 4.0 Then this PR which includes breaking changes which were meant to be deprecated in 3.x cannot be released anymore in 4.x from my understanding and only in 5.x and the PR #6080 without the breaking changes need to be redone for 4.x? This is way more work than I can put into this ATM |
Sorry we didn't warn you about it, we had a lot on our plate and this apparently fell through the cracks.
Yes, exactly. There is very little difference between 5.0.x and 4.1.x right now, so the most convenient time to do it is now. I think what you can do is:
|
Should the revert be for 3.9 or 4.1 ? If it's for 4.x we still have the same problem with tons of conflict with v4 so it's easier to start from this PR and simply revert the breaking changes using the old PR I could open 3 PRs, one against 3.9 again without breaking change which is basically the old reverted PR, 4.1 which is this port still but without breaking changes and 5.0.x which is this PR |
Sorry, I'm kinda busy right now, but I haven forgotten this PR. Promise!
|
Merges the changes of #6080 into 4.0.x