dotkernel / admin

DotKernel Admin Application, built on top of Mezzio microframework and using Laminas components.
https://admin5.dotkernel.net
MIT License
30 stars 5 forks source link

redefine ENUMs with enumType #212

Open arhimede opened 10 months ago

arhimede commented 10 months ago

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

alexmerlin commented 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:

  1. 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)

  2. 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.

arhimede commented 10 months ago

@kakapiciu will try to implement a proof of concept solution 2, variant #2