SchemaValidator is complaining about BIGINT with PHP typehint int

[ThomasLandauer]

Bug Report

Q	A
BC Break	no
Version	3.1.0 and DBAL 4.0.1

Summary

With this mapping:

#[ORM\Column(type: Types::BIGINT, nullable: true)]
private ?int $foo = null;

... Symfony Profiler is reporting a Mapping Error:

The field 'Bar#foo' has the property type 'int' that differs from the metadata field type 'string' returned by the 'bigint' DBAL type.

Which is kinda right according to the docs at https://www.doctrine-project.org/projects/doctrine-dbal/en/4.0/reference/types.html#bigint :

Values retrieved from the database are always converted to PHP's integer type if they are within PHP's integer range or string if they aren't.

But according to #11073 (comment) , a BIGINT should be typehinted as int:

Then before migrating to 4.0.0, you change the type to string|int, ignore the warning, and change to int after the migration.

So what is the recommended typehint now?

I think there should be a recommendation in the docs, maybe I can add it to doctrine/dbal#6336

[greg0ire]

So what is the recommended typehint now?

I'd say it is int|string?

I think there should be a recommendation in the docs, maybe I can add it to doctrine/dbal#6336

You want to make a recommendation about entities in the DBAL docs?

[ThomasLandauer]

You want to make a recommendation about entities in the DBAL docs?

Well, what's currently said at https://www.doctrine-project.org/projects/doctrine-dbal/en/4.0/reference/types.html#bigint is OK IMO.

So what I really mean in this issue is that this line needs to be changed: https://github.com/doctrine/orm/blob/3.1.x/src/Tools/SchemaValidator.php#L56
Is the solution really as simple as putting string|int in there? (The order is taken from https://www.php.net/manual/en/reflectionuniontype.gettypes.php#128871 )

[greg0ire]

Is the solution really as simple as putting string|int in there? (The order is taken from php.net/manual/en/reflectionuniontype.gettypes.php#128871 )

The best way to find out is to try I guess.

[ThomasLandauer]

Well then - see #11396