Generated migrations do not consider columnDefinition=... clause

[jean553]

doctrine/doctrine-migrations-bundle 3.3.1
octrine/dbal 3.9.1

The content of columnDefinition=... is not part of the generated migration.

For instance:

 #[ORM\Column(
    type: 'string',
    length: 255,

    // custom column definition content here...
    columnDefinition: "VARCHAR(255) UNIQUE")
]
private string $lastName;

When using the doctrine:migrations:diff or doctrine:migrations:migrate, the generated migration does not contain the custom column definition. According to the documentation here, this custom setting should be set in the migration.

[greg0ire]

From the documentation you linked:

SchemaTool will not detect changes on the column correctly anymore if you use columnDefinition.

If the ORM's schema tool cannot detect the changes, why do you expect that to work when using doctrine/migrations? Both rely on the same DBAL APIs.

According to the documentation here, this custom setting should be set in the migration.

Sorry, where exactly does it say that?

[allan-simon]

@greg0ire is the SchemaTool limitation a hard limitation, or just it's a nice feature and nobody bothered to implement it yet ? by that I mean, is doing a PR a lost cause (because not possible with the dbal architecture) or is it feasible ? (in that case I may give it a try)

[greg0ire]

I think it has been a lost cause in the past, but now that we have platform-aware comparison, it might be thinkable. Also, I don't think the limitation will have to do with SchemaTool or doctrine/migrations, but with doctrine/dbal. I might be completely wrong though. In any case, maybe what you could do first is research this topic and improve the document to link to something authoritative and more elaborate, like this discussion if you end up posting an overview of the issue on it.

@derrabus @morozov WDYT?

@derrabus I wonder if it could be done through the VerbatimType you talked about in doctrine/migrations#1441 (comment)

[morozov]

I think it's worth giving it a try.

The current implementation compares SQL to SQL and (as previously) ignores the custom declaration:

dbal/src/Platforms/AbstractPlatform.php

Lines 2221 to 2230 in 0f0398a

	// ignore explicit columnDefinition since it's not set on the Column generated by the SchemaManager
	unset($column1Array['columnDefinition']);
	unset($column2Array['columnDefinition']);
	if (
	$this->getColumnDeclarationSQL('', $column1Array)
	!== $this->getColumnDeclarationSQL('', $column2Array)
	) {
	return false;
	}

If instead of unsetting 'columnDefinition', we make getColumnDeclarationSQL() respect it (as it’s done during the actual DDL generation), it may work.

However, I think the problem is that the custom SQL provided by the user will unlikely ever match the SQL generated by the DBAL (because otherwise, why would they provide it to begin with?), and this will cause infinite schema mismatch.

[jean553]

If the ORM's schema tool cannot detect the changes, why do you expect that to work when using doctrine/migrations? Both rely on the same DBAL APIs.

@greg0ire OK, mistake from me then, I misunderstood this. I though the content of the columnDefinition was a kind of "custom content" always appended "as it is" to the generated migration. Indeed, this is not how it is supposed to work.

Thanks for considering a potential implementation anyway.