Tame doctrine migrations / determine which we want to apply. #1917
Tame doctrine migrations / determine which we want to apply. #1917johanib wants to merge 1 commit intoupgrade-84from
Conversation
b83392f to
156245f
Compare
Prior to this change, doctrine wants to change the longtext types of consent_settings and idp_discoveries to `json`. This has some implications, as at a db level, as it requires a migration. This migration is not strictly needed. Ensure no database migrations are applied by configuring doctrine to use the old legacy mappings, until we have reason to upgrade in a coordinated operation. Even with this change, doctrine wants to remove the comments. But we can safely apply this in the next release, without causing any big migrations.
e9849bf to
3eebb07
Compare
| // We want a `TEXT` field declaration in our column, the `LONGTEXT` default causes issues when running the | ||
| // DBMS in strict mode. | ||
| $column['length'] = 65535; | ||
| return $platform->getJsonTypeDeclarationSQL($column); | ||
| $column['length'] = null; // Ensure a longtext, this is currently on prod. | ||
| return $platform->getClobTypeDeclarationSQL($column); |
There was a problem hiding this comment.
The comment on l33..34 contradict the comment on l35. No doubt the new comment is correct and reflects the real world situation. Maybe remove the old comment to prevent questions in the future?
Also this makes me wonder. Was the longtext issue we ran into before fixed in the DBMS? Or..
|
|
||
| public function getSQLDeclaration(array $column, AbstractPlatform $platform): string | ||
| { | ||
| return $platform->getClobTypeDeclarationSQL([]); |
There was a problem hiding this comment.
Below, you explicitly pass length = null to ensure no data changes occur. Maybe for consistency sake do this here to? I know the default length is null if you do not pass it.
Also here you do not pass the $column configuration to the getClobTypeDeclarationSQL method. Which is intentional and I get it. It is different from the other custom type implementations. Maybe give that a quick extra thought before merging this. 🤸♂️
| * | ||
| * Use this type instead of Doctrine\DBAL\Types\Types::JSON for columns that should remain as longtext. | ||
| */ | ||
| class LegacyJsonType extends Type |
There was a problem hiding this comment.
The other types got some nice'n shiny tests. Why not generate some for this custom type?
| * This type stores JSON data in a longtext column, deliberately avoiding migration to a native MySQL JSON column type. | ||
| * The native JSON column type (declared via getJsonTypeDeclarationSQL) was introduced when upgrading to doctrine/dbal:^4, | ||
| * but migrating existing longtext columns to JSON columns is not desirable at this time. |
There was a problem hiding this comment.
Perhaps you could advertise that the column definitions that can be passed in the ORM column definition attribute are NOT passed along to the ORM and that only the default column definition is used for this type?
Prior to this change, doctrine wants to change the longtext types of consent_settings and idp_discoveries to
json. This has some implications, as at a db level, as it requires a migration. This migration is not strictly needed.Ensure no database migrations are applied by configuring doctrine to use the old legacy mappings, until we have reason to upgrade in a coordinated operation.
Even with this change, doctrine wants to remove the comments. But we can safely apply this in the next release, without causing any big migrations.
After this change, doctrine wants to create a migration for this.
Before this change, Doctrine wanted to migrate to this: