Invalid field error reported for bigint DBAL type #7251

@emodric commented on GitHub (Nov 20, 2023):

What I really wanted to say is that it would be nice to allow usage of bigint with int PHP typehint, allowing up to 64bit size integer values, without having the warning in the logs.

@emodric commented on GitHub (Nov 20, 2023): What I really wanted to say is that it would be nice to allow usage of `bigint` with `int` PHP typehint, allowing up to 64bit size integer values, without having the warning in the logs.

admin commented

@dmamchyts commented on GitHub (Nov 21, 2023):

The same issue after upgrade from

        "doctrine/doctrine-bundle": "^2.11.0",
        "doctrine/orm": "^2.16.2",

to

        "doctrine/doctrine-bundle": "^2.11.1",
        "doctrine/orm": "^2.17.1",

Entity:

#[ORM\Entity(repositoryClass: UserRepository::class)]
#[ORM\HasLifecycleCallbacks]
#[ORM\Table(name: 'users')]
class User extends AbstractEntity implements UserInterface
{
...
    #[ORM\Column(type: Types::BIGINT, nullable: true, unique: true)]
    protected ?int $facebookId = null;
...

error:

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

@dmamchyts commented on GitHub (Nov 21, 2023): The same issue after upgrade from ``` "doctrine/doctrine-bundle": "^2.11.0", "doctrine/orm": "^2.16.2", ``` to ``` "doctrine/doctrine-bundle": "^2.11.1", "doctrine/orm": "^2.17.1", ``` Entity: ``` #[ORM\Entity(repositoryClass: UserRepository::class)] #[ORM\HasLifecycleCallbacks] #[ORM\Table(name: 'users')] class User extends AbstractEntity implements UserInterface { ... #[ORM\Column(type: Types::BIGINT, nullable: true, unique: true)] protected ?int $facebookId = null; ... ``` error: ``` The field 'App\Common\Entity\User#facebookId' has the property type 'int' that differs from the metadata field type 'string' returned by the 'bigint' DBAL type. ```

admin commented

@greg0ire commented on GitHub (Nov 21, 2023):

@emodric @dmamchyts it's unclear to me whether you have read and understood https://github.com/doctrine/orm/issues/10944

@greg0ire commented on GitHub (Nov 21, 2023): @emodric @dmamchyts it's unclear to me whether you have read and understood https://github.com/doctrine/orm/issues/10944

admin commented

@emodric commented on GitHub (Nov 21, 2023):

Yes, and so far I haven't had issues with performance.

@emodric commented on GitHub (Nov 21, 2023): Yes, and so far I haven't had issues with performance.

admin commented

2026-01-22 15:48:10 +01:00

@greg0ire commented on GitHub (Nov 21, 2023):

Ok, so… if you were starting from scratch, you would not be using bigint then, since you don't plan on using values larger than 64 bit integers, right? This must have to do with a wrong, maybe legacy choice that is hard to change now, correct?

@greg0ire commented on GitHub (Nov 21, 2023): Ok, so… if you were starting from scratch, you would not be using `bigint` then, since you don't plan on using values larger than 64 bit integers, right? This must have to do with a wrong, maybe legacy choice that is hard to change now, correct?

admin commented

@emodric commented on GitHub (Nov 22, 2023):

Not really. Isn't bigint in MySQL used for 64bit integers?

https://dev.mysql.com/doc/refman/8.0/en/integer-types.html

@emodric commented on GitHub (Nov 22, 2023): Not really. Isn't `bigint` in MySQL used for 64bit integers? https://dev.mysql.com/doc/refman/8.0/en/integer-types.html

admin commented

2026-01-22 15:48:10 +01:00

@greg0ire commented on GitHub (Nov 22, 2023):

I wrongly thought it would allow integers larger than 64 bits because you stated:

especially, since we do not need values larger than 64bit integers.

Now I fail to understand the logic in your first message. Did you mean to write "since we do not need values larger than PHP_INT_MAX"? On my system, PHP_INT_MAX is smaller than 2**64

@greg0ire commented on GitHub (Nov 22, 2023): I wrongly thought it would allow integers larger than 64 bits because you stated: > especially, since we do not need values larger than 64bit integers. Now I fail to understand the logic in your first message. Did you mean to write "since we do not need values larger than `PHP_INT_MAX`"? On my system, `PHP_INT_MAX` is smaller than `2**64`

admin commented

@emodric commented on GitHub (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 commented on GitHub (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.

admin commented

@dmamchyts commented on GitHub (Nov 22, 2023):

If I understand correctly https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#bigint - in 4.0.0 current issue will be fixed?

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. Otherwise, returns null if no data is present.

@dmamchyts commented on GitHub (Nov 22, 2023): If I understand correctly https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#bigint - in 4.0.0 current issue will be fixed? _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. Otherwise, returns null if no data is present._

admin commented

@greg0ire commented on GitHub (Nov 22, 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 commented on GitHub (Nov 22, 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.

admin commented

@dmamchyts commented on GitHub (Nov 22, 2023):

Looks like I can ignore minor/patch releases (if no any performance issues).
Wait for the release of 4.0.0 and only then update libraries
No any changes in code-base.

Do you have any ETA about the release 4.0.0?

@dmamchyts commented on GitHub (Nov 22, 2023): Looks like I can ignore minor/patch releases (if no any performance issues). Wait for the release of 4.0.0 and only then update libraries No any changes in code-base. Do you have any ETA about the release 4.0.0?

admin commented

@greg0ire commented on GitHub (Nov 22, 2023):

I'd say months if not weeks.

@greg0ire commented on GitHub (Nov 22, 2023): I'd say months if not weeks.

admin commented

2026-01-22 15:48:12 +01:00

@derrabus commented on GitHub (Nov 22, 2023):

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 commented on GitHub (Nov 22, 2023): > 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.

admin commented

@bobvandevijver commented on GitHub (Nov 23, 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 commented on GitHub (Nov 23, 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.

admin commented

2026-01-22 15:48:12 +01:00

@greg0ire commented on GitHub (Nov 23, 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 commented on GitHub (Nov 23, 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. ```php class MyEntity { #[SuppressValidationError('invalid_type')] private float $myDecimal; } ``` Not saying I will build it, but still, might be cool.

admin commented

@vitxd commented on GitHub (Dec 13, 2023):

Hello, since I've updated doctrine dbal I have this issue as well as others that seems related when using enums as type, for example:

The field 'App\Entity\CertificateEvent#type' has the property type 'App\Enum\EventType' that differs from the metadata field type 'string' returned by the 'string' DBAL type.

do you think is related?

@vitxd commented on GitHub (Dec 13, 2023): Hello, since I've updated doctrine dbal I have this issue as well as others that seems related when using enums as type, for example: ``` The field 'App\Entity\CertificateEvent#type' has the property type 'App\Enum\EventType' that differs from the metadata field type 'string' returned by the 'string' DBAL type. ``` do you think is related?

admin commented

@greg0ire commented on GitHub (Dec 13, 2023):

I'd need to see EventType to answer that. Also, we might want to improve the code introduced in #11039, it produces an error that does not mention the backing type, Cc @yceruto

@greg0ire commented on GitHub (Dec 13, 2023): I'd need to see `EventType` to answer that. Also, we might want to improve the code introduced in #11039, it produces an error that does not mention the backing type, Cc @yceruto

admin commented

@yceruto commented on GitHub (Dec 13, 2023):

@vitxd can you show us the mapping code for that field?

@yceruto commented on GitHub (Dec 13, 2023): @vitxd can you show us the mapping code for that field?

admin commented

@yceruto commented on GitHub (Dec 13, 2023):

What is the backed type of your App\Enum\EventType?

@yceruto commented on GitHub (Dec 13, 2023): What is the backed type of your `App\Enum\EventType`?

admin commented

2026-01-22 15:48:14 +01:00

@vitxd commented on GitHub (Dec 13, 2023):

Yes sorry @yceruto, I just realised is an interface. implementations are

enum InstructionEventType: string implements EventType
{
}

enum CertificateEventType: string implements EventType
{
}

the mapping is:

<entity name="App\Entity\CertificateEvent">
    <field name="type" type="string" column="type" enum-type="App\Enum\CertificateEventType" nullable="false" />

CertificateEvent looks like:

class CertificateEvent extends CaseEvent
{
    public function __construct(
        ApplicationCase $case,
        CertificateEventType $type
    ) {
      parent::__construct($case, $type);
    }

abstract class CaseEvent
{
    public function __construct(
        protected ApplicationCase $case,
        protected EventType $type,
    ) {

@vitxd commented on GitHub (Dec 13, 2023): Yes sorry @yceruto, I just realised is an interface. implementations are ```php enum InstructionEventType: string implements EventType { } enum CertificateEventType: string implements EventType { } ``` the mapping is: ```xml <entity name="App\Entity\CertificateEvent"> <field name="type" type="string" column="type" enum-type="App\Enum\CertificateEventType" nullable="false" /> ``` CertificateEvent looks like: ```php class CertificateEvent extends CaseEvent { public function __construct( ApplicationCase $case, CertificateEventType $type ) { parent::__construct($case, $type); } ``` ```php abstract class CaseEvent { public function __construct( protected ApplicationCase $case, protected EventType $type, ) { ```

admin commented

@greg0ire commented on GitHub (Dec 13, 2023):

Then I think it's unrelated, and you should file a separate issue. This is probably specific to either interfaces or enums. I'll mark our conversation as off-topic so that people concerned by the original issue don't bother reading them.

@greg0ire commented on GitHub (Dec 13, 2023): Then I think it's unrelated, and you should file a separate issue. This is probably specific to either interfaces or enums. I'll mark our conversation as off-topic so that people concerned by the original issue don't bother reading them.

admin commented

2026-01-22 15:48:14 +01:00

@vitxd commented on GitHub (Dec 15, 2023):

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

@vitxd commented on GitHub (Dec 15, 2023): Is this issue being fixed by the way? I have this problem too as well as the other you've already fixed (thanks!)

admin commented

@mindaugasvcs commented on GitHub (Jan 10, 2024):

Why Doctrine devs did not check PHP_INT_SIZE in Doctrine\DBAL\Types\BigIntType and cast to string for value 4 and cast to int for value 8? :/

@mindaugasvcs commented on GitHub (Jan 10, 2024): Why Doctrine devs did not check PHP_INT_SIZE in Doctrine\DBAL\Types\BigIntType and cast to string for value 4 and cast to int for value 8? :/

admin commented

@greg0ire commented on GitHub (Jan 11, 2024):

@vitxd there is https://github.com/doctrine/orm/pull/11130 that might be of help

@mindaugasvcs I don't think I 100% understand your question, but having an application behave differently based on PHP_INT_SIZE sounds like a terrible idea.

@greg0ire commented on GitHub (Jan 11, 2024): @vitxd there is https://github.com/doctrine/orm/pull/11130 that might be of help @mindaugasvcs I don't think I 100% understand your question, but having an application behave differently based on `PHP_INT_SIZE` sounds like a terrible idea.

admin commented

@mindaugasvcs commented on GitHub (Jan 11, 2024):

@vitxd there is #11130 that might be of help @mindaugasvcs I think I 100% understand your question, but having an application behave differently based on PHP_INT_SIZE sounds like a terrible idea.

Of course always casting to a 'string' is much nicer when in fact it should be int as 32-bit systems are dead by now.

@mindaugasvcs commented on GitHub (Jan 11, 2024): > @vitxd there is #11130 that might be of help @mindaugasvcs I think I 100% understand your question, but having an application behave differently based on `PHP_INT_SIZE` sounds like a terrible idea. Of course always casting to a 'string' is much nicer when in fact it should be int as 32-bit systems are dead by now.

admin commented

@greg0ire commented on GitHub (Jan 11, 2024):

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 commented on GitHub (Jan 11, 2024): 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

admin commented