dbal
dbal copied to clipboard
Type Mapping Discrepancies Between DBAL3 and DBAL4
Q | A |
---|---|
Version | 4.0.x |
This PR https://github.com/doctrine/dbal/pull/6463 and this topic https://github.com/doctrine/migrations/issues/1441 have highlighted a peculiar behavior.
In this case, let's consider the inet
type, which was added to the PostgreSQL platform a long time ago - https://github.com/doctrine/dbal/blob/90424473eb144659a89fb1b5c9bca37297085351/src/Platforms/PostgreSQLPlatform.php#L706
After some tests, I noticed that in DBAL3 and DBAL4 they behave strangely. I suspect that inet
was added there to work around an issue because Doctrine did not recognize this type. That is, if we have such a migration in DBAL3:
CREATE TABLE test_inet (
id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
ip_inet INET NOT NULL,
PRIMARY KEY(id)
);
And such an entity:
#[ORM\Table(name: "test_inet")]
#[ORM\Entity]
class TestInet
{
#[ORM\Id]
#[ORM\Column(name: "id", type: Types::INTEGER, nullable: false)]
#[ORM\GeneratedValue(strategy: "IDENTITY")]
private ?int $id = null;
#[ORM\Column(name: "ip_inet", type: Types::STRING, nullable: false)]
private string $ipInet;
}
Then DBAL3 will ignore the fact that the migration type is INET
, deciding that it is VARCHAR
and will keep the type as INET
. However, in DBAL4, this trick no longer works, and we have to redefine the type as follows:
doctrine:
dbal:
mapping_types:
inet: override_inet
types:
override_inet: { class: 'App\Entity\InetType' }
#[ORM\Table(name: "test_inet")]
#[ORM\Entity]
class TestInet
{
#[ORM\Id]
#[ORM\Column(name: "id", type: Types::INTEGER, nullable: false)]
#[ORM\GeneratedValue(strategy: "IDENTITY")]
private ?int $id = null;
#[ORM\Column(name: "ip_inet", type: 'override_inet', nullable: false)]
private string $ipInet;
}
So, my question, what function does inet
perform in initializeDoctrineTypeMappings()
or other similar custom types? And isn't this a bug? Or am I using or understanding it incorrectly?
Therefore, I afraid that if the PR https://github.com/doctrine/dbal/pull/6463 is applied to DBAL4 in the same way, it will not work correctly and will cause the same problems.
Thanks.