Skip to content

Symfony & Doctrine Mapping problems with MySQL Bigint columns, and how to fix this

In the process of upgrading a Symfony project from version 2 to version 5, I came across an issue with a MySQL table that has a number of BIGINT columns. There had been no issue previously, but after updating to the newer symfony (and doctrine components) mySQL bigint columns were empty/null in my doctrine entities.

After some investigation I came upon this section of the Doctrine manual:

For compatibility reasons this type is not converted to an integer as PHP can only represent big integer values as real integers on systems with a 64-bit architecture and would fall back to approximated float values otherwise which could lead to false assumptions in applications.

To protect symfony apps running on 32 bit systems, Doctrine maps Bigint columns to the string type, and this broke the entity definition I was using, even though my application will only be deployed on 64 bit systems. I think that for most people this is the norm.

There are a few different ways to get around this issue, including type casting from string to integer/integer to string in your getters and setters, but if you have a lot of bigint columns across tables, that probably isn't a great solution. In this article, I present the solution I implemented, which utilizes a Custom Doctrine type to override the built in Doctrine behavior.
Continue reading "Symfony & Doctrine Mapping problems with MySQL Bigint columns, and how to fix this"