Prevent column flagging as diff just because type differs (when one type is parent to other)

[jesparic]

Q	A
Type	improvement
BC Break	no
Fixed issues	No direct issue but builds on change made for #3427

Summary

The ability to extend the dbal type system allows us to define our own Enum implementations. Often these extend from the StringType built-in type class. Everything works as it should except for one caveat - when generating migration diffs the Comparator::diffColumn() will detect that the two types are not identical and add the column to the generated migration diff every time. This leaves us with 2 main choices:

1. Manually remove the diffs from the generated migration files each time (not ideal and prevents us from using the diff in CI tasks effectively)
2. Add Type::requiresSQLCommentHint() == true method to our extension class

Although a perfectly reasonable solution, in some cases #2 is less than ideal (i.e., if we don't want to make modifications to the schema columns). For example, when porting a legacy app where the source of truth (and legacy migration system) is still the old app. In this case, we use the diff not to migrate the changes, but instead to make our schema continually match the legacy app while the migration work continues (i.e., the legacy app can and will still change).

To satisfy the above use case, I have presented this pull request. I have added a small modification to the Comparator::diffColumn() method which basically checks if the second check type is a subclass of the parent and that the parent is a basic string type. If this is the case, then the 'type' diff is not added; i.e., Only detected differences in options will then cause the schema diff to report change to the column

To summarise, I think implementing an enum as an extension of the string class is a very common case and I don't see a strong reason to enforce/require requiresSQLCommentHint() for the type in this case (Doctrine is perfectly able to detect and hydrate the type correctly at runtime)

Kind regards,
Richard

[SenseException]

I'm not sure about this feature being in 2.10. If this will be considered to be added to DBAL, I would suggest the next minor version.

[SenseException]

Often these extend from the StringType built-in type class.

This seems to be a hard coded specific change for your enum use case. What about types that use StringType too but are supposed to be mentioned in changes? I personally wouldn't build upon an existing type.