Add type inferral for backed enums in Parameter as part of QueryBuilder #6903

New Issue

2026-01-22T15:41:00+01:00

admin commented

2026-01-22 15:41:00 +01:00

Originally created by @tomudding on GitHub (Jan 12, 2022).

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

With the release of v2.11.0 just a few hours ago, support for PHP 8.1's enums was added. This works great, however, I would like to see that the setParameter() function (or rather the Parameter which is created in that function) has support for automatically inferring the type of backed enums.

Here an example:

enum Suit: int {
    case Hearts = 0;
    case Diamonds = 1; 
    case Clubs = 2;
    case Spades = 3;
}

#[Entity]
class Card
{
    /** ... */

    #[Column(type: "integer", enumType: Suit::class)]
    private Suit $suit;

Then at some point you could want to do something along the of:

$qb = $em->getRepository(Card::class)->createQueryBuilder('c');
$qb->where('c.suit = :suit')
    ->setParameter('suit', Suit::Hearts); // instead of Suit::Hearts->value

$qb->getQuery->getResult();

However, now you get the following error:

Error: Object of class Suit could not be converted to string.

Where I would have expected it to say integer. string is given because it is the default type (\Doctrine\DBAL\ParameterType::STRING) in \Doctrine\ORM\Query\ParameterTypeInferer::inferType. Which has no knowledge of what a backed enum is.

Clearly, this is also shows that DBAL is incomplete, as it has no idea what to do with the enum (which type of backed enum does not matter, you could force \Doctrine\DBAL\Types\Types::INTEGER in setParameter and DBAL would complain about being unable to convert the enum into an integer). However, that is an separate issue and not what this feature request is about (but it does depend on each other).

Originally created by @tomudding on GitHub (Jan 12, 2022). ### Feature Request  | Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | no #### Summary With the release of v2.11.0 just a few hours ago, support for PHP 8.1's enums was added. This works great, however, I would like to see that the `setParameter()` function (or rather the `Parameter` which is created in that function) has support for automatically inferring the type of backed enums. Here an example: ```php enum Suit: int { case Hearts = 0; case Diamonds = 1; case Clubs = 2; case Spades = 3; } #[Entity] class Card { /** ... */ #[Column(type: "integer", enumType: Suit::class)] private Suit $suit; ``` Then at some point you could want to do something along the of: ```php $qb = $em->getRepository(Card::class)->createQueryBuilder('c'); $qb->where('c.suit = :suit') ->setParameter('suit', Suit::Hearts); // instead of Suit::Hearts->value $qb->getQuery->getResult(); ``` However, now you get the following error: > Error: Object of class Suit could not be converted to string. Where I would have expected it to say `integer`. `string` is given because it is the default type (`\Doctrine\DBAL\ParameterType::STRING`) in `\Doctrine\ORM\Query\ParameterTypeInferer::inferType`. Which has no knowledge of what a backed enum is. Clearly, this is also shows that DBAL is incomplete, as it has no idea what to do with the enum (which type of backed enum does not matter, you could force `\Doctrine\DBAL\Types\Types::INTEGER` in `setParameter` and DBAL would complain about being unable to convert the enum into an integer). However, that is an separate issue and not what this feature request is about (but it does depend on each other).

admin closed this issue

2026-01-22 15:41:00 +01:00

admin commented

2026-01-22 15:41:01 +01:00

@derrabus commented on GitHub (Jan 12, 2022):

Please try out #9373.

@derrabus commented on GitHub (Jan 12, 2022): Please try out #9373.

admin commented

2026-01-22 15:41:01 +01:00

@greg0ire commented on GitHub (Jan 13, 2022):

Clearly, this is also shows that DBAL is incomplete

Just for the record, it's unclear to me why the DBAL should know about enums… reading https://github.com/doctrine/orm/blob/c0a1404e4cd4ac23382388700a594621e10ff6b7/lib/Doctrine/ORM/AbstractQuery.php#L431-L445 , I'm under the impression that you can use setParameter with an entity, and the DBAL has no knowledge of entities either.

@greg0ire commented on GitHub (Jan 13, 2022): > Clearly, this is also shows that DBAL is incomplete Just for the record, it's unclear to me why the DBAL should know about enums… reading https://github.com/doctrine/orm/blob/c0a1404e4cd4ac23382388700a594621e10ff6b7/lib/Doctrine/ORM/AbstractQuery.php#L431-L445 , I'm under the impression that you can use `setParameter` with an entity, and the DBAL has no knowledge of entities either.

admin commented

2026-01-22 15:41:02 +01:00

@tomudding commented on GitHub (Jan 13, 2022):

Please try out #9373.

@derrabus Thank you for looking into this! I have tested the PR and it works as expected, much appreciated.

Clearly, this is also shows that DBAL is incomplete

Just for the record, it's unclear to me why the DBAL should know about enums… reading

https://github.com/doctrine/orm/blob/c0a1404e4cd4ac23382388700a594621e10ff6b7/lib/Doctrine/ORM/AbstractQuery.php#L431-L445
, I'm under the impression that you can use setParameter with an entity, and the DBAL has no knowledge of entities either.

@greg0ire My apologies, totally an oversight and misunderstanding on my part! There is indeed no reason that DBAL should be expected to know anything about "complex" objects (potentially passed on from ORM), only data in one of its primitive types.

@tomudding commented on GitHub (Jan 13, 2022): > Please try out #9373. @derrabus Thank you for looking into this! I have tested the PR and it works as expected, much appreciated. > > Clearly, this is also shows that DBAL is incomplete > > Just for the record, it's unclear to me why the DBAL should know about enums… reading > > https://github.com/doctrine/orm/blob/c0a1404e4cd4ac23382388700a594621e10ff6b7/lib/Doctrine/ORM/AbstractQuery.php#L431-L445 > , I'm under the impression that you can use `setParameter` with an entity, and the DBAL has no knowledge of entities either. @greg0ire My apologies, totally an oversight and misunderstanding on my part! There is indeed no reason that DBAL should be expected to know anything about "complex" objects (potentially passed on from ORM), only data in one of its primitive types.

admin commented

2026-01-22 15:41:02 +01:00

@pkly commented on GitHub (Jan 31, 2022):

I would also like to see this working, as I've just had the same issue, but this time with the findBy / findOneBy methods.

On that point, why not just handle this simple conversion inside of Dbal/Connection same as is done with arrays inside of executeQuery?
As a helper it could be done in a query builder but the type information really should be available when using things like findBy, otherwise crashes will occur.

@pkly commented on GitHub (Jan 31, 2022): I would also like to see this working, as I've just had the same issue, but this time with the findBy / findOneBy methods. On that point, why not just handle this simple conversion inside of Dbal/Connection same as is done with arrays inside of executeQuery? As a helper it could be done in a query builder but the type information really should be available when using things like findBy, otherwise crashes will occur.

admin commented

2026-01-22 15:41:02 +01:00

@derrabus commented on GitHub (Jan 31, 2022):

Closing because this feature has been implemented in #9373.

@derrabus commented on GitHub (Jan 31, 2022): Closing because this feature has been implemented in #9373.

admin commented

2026-01-22 15:41:03 +01:00

@derrabus commented on GitHub (Jan 31, 2022):

@pkly Can you please give #9453 a try?

@derrabus commented on GitHub (Jan 31, 2022): @pkly Can you please give #9453 a try?

admin commented

2026-01-22 15:41:03 +01:00

@pkly commented on GitHub (Feb 1, 2022):

@derrabus I'm unable to test them at this moment. I did look at both MRs and they look good to me, so as soon as 2.12 releases I'll update my project and check.

@pkly commented on GitHub (Feb 1, 2022): @derrabus I'm unable to test them at this moment. I did look at both MRs and they look good to me, so as soon as 2.12 releases I'll update my project and check.

admin commented

2026-01-22 15:41:04 +01:00

@tourze commented on GitHub (Apr 10, 2022):

Good feature, when can we test it on 2.12.x ?

@tourze commented on GitHub (Apr 10, 2022): Good feature, when can we test it on 2.12.x ?

admin commented

2026-01-22 15:41:04 +01:00

@derrabus commented on GitHub (Apr 10, 2022):

Good feature, when can we test it on 2.12.x ?

Nobody's holding you back.

@derrabus commented on GitHub (Apr 10, 2022): > Good feature, when can we test it on 2.12.x ? Nobody's holding you back.

admin commented

2026-01-22 15:41:04 +01:00

@pkly commented on GitHub (May 5, 2022):

Oh yeah I forgot to mention it but it seems it works perfectly fine ever since I upgraded to 2.12.
Many thanks

@pkly commented on GitHub (May 5, 2022): Oh yeah I forgot to mention it but it seems it works perfectly fine ever since I upgraded to 2.12. Many thanks

admin referenced this issue

2026-01-22 16:06:47 +01:00

[PR #6903] Travis: Allow failures for tests on non-SQLite RDBMS, disable SLC tests #10202

Sign in to join this conversation.