Open arhimede opened 10 months ago
Solution 1: Mapping to Varchars is what we're currently using and as we know, it has it's own flaws (showing unnecessary modifications in each migration).
Solution 2: Defining a Type seems to be the preferred approach in most frameworks. In addition to the method described in the article, there should be either:
An abstract type that then could be extended by each custom enumType
abstract class AbstractEnumType extends Type
containing all the methods defined in the article (getSQLDeclaration
, convertToPHPValue
etc)
Then custom enumTypes extending AbstractEnumType that have only one purpose, providing the values (which can be defined as constants in the custom enumType and also used in the $values array - this way the values are defined only once and constants can also be reused outside the class)
One single enumType that when added to a property, can be configured (if needed, the values
parameter's name can be changed to a more suitable one):
#[ORM\Column(name: "status", type: EnumType::class, values: ["pending", "active"])]
If this can be implemented, it would be the easisest solution both to write and to use.
Note: Both solutions (the abstract / generic enumTypes) are theoretical, I did not try them in practice. Their purpose is only to give an idea on where to start implementing these types.
@kakapiciu will try to implement a proof of concept solution 2, variant #2
https://www.doctrine-project.org/projects/doctrine-orm/en/2.17/cookbook/mysql-enums.html
https://stackoverflow.com/questions/73907769/how-to-mapping-type-enums-in-doctrine
@alexmerlin please give us an idea here if we should replace enum with enumType