orm: Invalid field error reported for bigint DBAL type

Bug Report

The field 'App\Entity\Message#id' has the property type 'int' that differs
from the metadata field type 'string' returned by the 'bigint' DBAL type.

Q	A
BC Break	no
Version	2.17.1

Summary

I have an entity with a bigint primary key, wich has an int typehint in the entity class. I realize from the error message that bigint uses string internally, but so far, there was no issues with using int typehint, especially, since we do not need values larger than 64bit integers.

Current behavior

After upgrading to Doctrine ORM 2.17.1, the above error is shown in logs.

How to reproduce

<entity name="App\Entity\Message">
    <id name="id" type="bigint">
        <generator />
    </id>
</entity>

class Message
{
    private int $id;
}

Expected behavior

No error message is reported.

About this issue

Original URL
State: closed
Created 7 months ago
Comments: 28 (16 by maintainers)

Most upvoted comments

Do you have any ETA about the release 4.0.0?

Soon’ish, but it will require you to upgrade to ORM 3 as well.

I have the same issue on one of my projects as well and my fear is that this error incentivizes people to change all their BIGINT properties to string just to run into the same issue once they upgrade to DBAL 4 one fine day. With a smooth upgrade path in mind, typing BIGINT properties as int should be correct and we should try to make it work in ORM 2 already.

Also, a lot of projects have the schema validation in their CI (which is good!) and now this new check (which is absolutely reasonable!) blocks the ORM upgrade unless the schema validation is either disabled completely or all errors have been fixed.

In the project where I have this problem, we have twenty-something properties that have the infamous DECIMAL + float type mismatch that motivated this new check. Each of them needs an individual solution, so it might take us a while. It would be good, if we could baseline or silence this issue somehow for the time being.

derrabus on Nov 26, 2023

Might be cool to have some kind of baseline concept but for that we would first need to come up with identifiers for each and every issue. Or at least for this one, as a start. Then I guess that system could be developed so that it’s possible to baseline issues per entity/property/whatever. Might even be call to use PHP attributes to that end.

class MyEntity
{
    #[SuppressValidationError('invalid_type')]
    private float $myDecimal;
}

Not saying I will build it, but still, might be cool.

greg0ire on Nov 23, 2023

Indeed, I forgot about that. The related PR is https://github.com/doctrine/dbal/pull/6177

Not sure what to do now… I don’t think there is an upgrade path for this particular breaking change. I think the right course of action for you is to use string as a type hint for now, and to add a method that casts it to int. And then, to never access the property directly, always go through the method.

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

greg0ire on Nov 22, 2023

Ah sorry, I did misunderstand. What you’re suggesting is actually more or less what’s going to happen with DBAL 4: https://github.com/doctrine/dbal/pull/6177

greg0ire on Jan 11, 2024

Is this issue being fixed by the way? I have this problem too as well as the other you’ve already fixed (thanks!)

vitxd on Dec 15, 2023

I have the same issue with float php type combined with decimal in the database: for us it is actually a great reminder that we need to update this anyways to something else, but it would indeed be nice to have some method to silence the issue for the time being.

bobvandevijver on Nov 23, 2023

I’d say months if not weeks.

greg0ire on Nov 22, 2023

Well, yes, that’s true, I meant PHP_INT_MAX, which is on my 64bit system equal to 2**63 -1, but I said 64bit colloquially, without taking into account signness of the integer value.

So, just to be clear, yes, we’re using bigint to allow values up to 2**63 - 1, which corresponds to PHP’s max integer value on 64bit systems.

emodric on Nov 22, 2023