Support for native PHP enums

[derrabus]

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

PHP 8.1 has introduced native enums to the language.

enum Suit: string {
  case Hearts = 'H';
  case Diamonds = 'D';
  case Clubs = 'C';
  case Spades = 'S';
}

#[Entity]
class Card
{
    #[Column, Id]
    public int $id;

    #[Column]
    public Suit $suit;
}

I'd like to use an enum as type of a property. The ORM should store the enums in a VARCHAR field using the backed value. When hydrating such an entity, the enum should be hydrated properly.

The resulting table card would look like this:

id	suit
1	H
2	H
3	S
4	C

[Nek-]

Using a VARCHAR looks weird because PostgresSQL, MariaDB, and MySQL support all enumerations. Is there any good reason (besides "it's work and we have nobody to do it") to not introduce the enumeration support in Doctrine?

Btw thank you very much for maintaining Doctrine!

[derrabus]

Using a VARCHAR looks weird

I disagree.

because PostgresSQL, MariaDB, and MySQL support all enumerations.

Yes, but others don't and I don't see why we should forbid using PHP enums on e.g. SQL Server.

Is there any good reason (besides "it's work and we have nobody to do it") to not introduce the enumeration support in Doctrine?

I personally stopped using native enums a long time ago because they rarely help. And from my point of view, they come with major drawbacks:

• There is (at least last time I checked) no elegant way to determine a list of enum members. This would make schema diffs for doctrine fairly complicated.
• Adding a new member to the enum means performing an ALTER TABLE. Depending on the size of your table, this can be a very expensive operation.
• MySQL enums behave weird for integer values.

Even if we added support for MySQL's ENUM type to Doctrine one fine day, it think it should not be our default solution for PHP enums.

[sicet7]

@derrabus

There is (at least last time I checked) no elegant way to determine a list of enum members.

Correct me if im wrong, but you should be able to call the method "cases" on the Enum to get a list of the members.
Atleast from what i have read of the PHP 8.1 UnitEnum Interface.

[greg0ire]

I think @Nek- was talking about database ENUM here, not PHP's Enum.
More reasons not to use enum here: http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

Also, I've used them myself at work recently, and failed to switch to varchar afterwards because the table I wanted to migrate has too many rows for the migration to go smoothly. So really, avoid ENUM.

[beberlei]

I believe we can support this on the ORM level if we add a new option to a fieldMapping enumType and allow setting enum fields using a new annotation, for example:

#[Enum(type: "string", class: Suit::class)]
public $suit;

#[Enum]
public Suit $autoSuit;

This way we get around the problem of DBAL types not being parameterized.

type can be string or integer or if people want their custom enum tpyes for the database.

Transformation could be done with either a new ReflectionEnumProperty on the setValue/getvalue level or with a check for $fieldMapping['enumType'] in hydrators/persisters.

[kadet1090]

This way we get around the problem of DBAL types not being parameterized.

type can be string or integer or if people want their custom enum tpyes for the database.

Transformation could be done with either a new ReflectionEnumProperty on the setValue/getvalue level or with a check for $fieldMapping['enumType'] in hydrators/persisters.

@beberlei Could we maybe implement this in more generic manner? If we expose not very specific to that particular use case enumType property but ability do attach generic converters (one of them could be builtin EnumConverter) we will open more possibilities for users. To name a few of this possibilities:

• deserializing JSON to actual objects (somewhat hacky solution: https://github.com/dunglas/doctrine-json-odm, very hacky: https://github.com/goodwix/doctrine-json-odm)
• transparently encrypting data in columns
• normalizing data to common format from multiple, entity specific, ones

Then, those value converters could attached like that:

#[Column(type: "string")]
#[ValueConverter(converter: EnumConverter::class, options: ["class" => Suit:class])]
public $suit;

Converters should be also attachable via the Events::loadClassMetadata to support more dynamic scenarios and also maybe dependency injection, as converters could have some more advanced logic.

Conversion process should probably look like that:

Hydration:
SQL Value -> Type::convertToPHPValue(...) -> ValueConverter::convertToEntityValue(..., type) (if applicable) -> PHP Value
Persistence:
PHP Value -> ValueConverter::convertToDatabaseValue(..., type) (if applicable) -> Type::convertToDatabaseValue(...) -> SQL Value

It will also allow users to have more control over how to store their enums, without limiting them to provided choices as it always will be possible to implement own converter for underlying type.

[greg0ire]

@kadet1090 it might be better to make Type instances parametrizable if we are going that way.

[kadet1090]

@greg0ire Personally I think that we could have both - Types could specify how value is stored inside database, and ValueConverters could provide way of converting those values into something that the class wants. But said that Type parametrization would allow to implement such behavior without much effort so I think that you're right that this would be overall better approach.