WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Conversation

@PaulCombal
Copy link

Q A
Type bug/improvement
Fixed issues doctrine/migrations#1542

Summary

For MySQL databases, the default value is always reported as being a string, which causes doctrine/migrations to be confused sometimes.

It's my first time contributing to Doctrine please be free to request edits.

@derrabus
Copy link
Member

derrabus commented Dec 4, 2025

Thank you for the PR. Please always add a test that reproduces the issue you're attempting to solve.

@morozov
Copy link
Member

morozov commented Dec 5, 2025

For MySQL databases, the default value is always reported as being a string, which causes doctrine/migrations to be confused sometimes.

I would attempt to fix that instead. Database drivers represent some numbers as strings for a reason.

Using floats for any kind of logic that involves comparison may just exacerbate the problem. Also, if we want to make such a change, it should be implemented and tested consistently across all supported platforms, not only MySQL.

@PaulCombal
Copy link
Author

PaulCombal commented Dec 5, 2025

What you're saying is that I should be handling this in doctrine/migrations instead of dbal, right?

@morozov
Copy link
Member

morozov commented Dec 5, 2025

Not necessarily. The problem may be in the DBAL itself but not in the schema manager but let's say in the comparator.

The best way to facilitate reasoning about the proper fix is to implement a failing scenario in code using the minimum of dependencies (e.g. w/o the ORM).

@PaulCombal
Copy link
Author

PaulCombal commented Dec 5, 2025

Thanks for the guidance. I moved the logic to AbstractPlatform::columnsEqual. Is this appropriate?

I will of course write tests for the change once a maintainer confirms the code is at the right place.

@morozov
Copy link
Member

morozov commented Dec 5, 2025

I will of course write tests

Please start with an integration test.

@PaulCombal PaulCombal reopened this Dec 12, 2025
@PaulCombal
Copy link
Author

Turns out the test was already there, but the test case was not. I added it here.

Thank you for your patience.

@derrabus
Copy link
Member

Apparently, your new test fails on SQL Server.

Comment on lines 2420 to 2431
$type1 = $column1Array['type'];
assert($type1 instanceof Type);
$type2 = $column2Array['type'];
assert($type2 instanceof Type);

if ($type1 instanceof Types\FloatType) {
$column1Array['default'] = $type1->convertToPHPValue($column1Array['default'], $this);
}

if ($type2 instanceof Types\FloatType) {
$column2Array['default'] = $type2->convertToPHPValue($column2Array['default'], $this);
}
Copy link
Member

Choose a reason for hiding this comment

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

It feels weird that a generic columnsEqual() method contains special treatment for one specific type. We should make sure that columnToArray() already produces comparable arrays.

Copy link
Author

Choose a reason for hiding this comment

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

I thought so too, but then I remembered being told above:

Database drivers represent some numbers as strings for a reason

Also that means that all database platforms must represent floats in the same way (which I hope they do) so I can just cast them to php values.

If you tell me that's the way to go I would happily do that!

@PaulCombal
Copy link
Author

Hi again, I implemented @derrabus 's solution instead, moving the logic into Column::toArray . It also fixes the test with mssql. Let me know if there's anything I can do to make this issue move forward.

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.

3 participants