Open michnovka opened 1 year ago
.1 autoconfiguration of enum types without having to type them all in doctrine yaml config […] at this point I still need to create this boilerplate for every enum but at least I dont have to register them then in doctrine.yaml
Currently, you don't have to write anything in doctrine.yaml
when using the elao_enum.doctrine.types
config, which generates the DBAL types and registers them for you using prependExtensionsConfig
.
So I would keep this mechanism. But we could perhaps add a mechanism to autodiscover the enums in a NS at compilation time and configure them using an optional PHP 8 attribute, rather than declaring explicitly each of the enum classes in the elao_enum
config.
- allow nullable field in DB, but non-nullable PHP field (so that if ENUM field in DB is NULL, it will fallback to some specific PHP enum value)
Isn't it covered by the current ORM implementation when using elao_enum.doctrine.types
config? (see the RequestStatus
example with default
)
- allow excluding some specific enum cases from the DB ENUM declaration
This use-case looks way too much specific to me to be implemented as-is in this package. But we can think of solutions to open extending the behavior of the generated DBAL types, through config, interfaces and/or annotations.
But we could perhaps add a mechanism to autodiscover the enums in a NS at compilation time and configure them using an optional PHP 8 attribute, rather than declaring explicitly each of the enum classes in the elao_enum config.
Yes, thats what I want
Isn't it covered by the current ORM implementation when using elao_enum.doctrine.types config? (see the RequestStatus example with default)
But again it requires a config entry. I would very much like to be able to define this on the enum level either as an attribute, or some function.
This use-case looks way too much specific to me to be implemented as-is in this package. But we can think of solutions to open extending the behavior of the generated DBAL types, through config, interfaces and/or annotations.
The use-case is actually I think very common, as if you have a Form in Symfony, and you want a to populate a field, and have some value to represent the null
DB value, then currently you cannot achieve this. So it will only be empty. See my example with membership type. I want null
to represent no membership. But currently, the only way to have this nicely displayed inside Symfony form is to create a custom type and override the options.
so how about we make an attribute
#[Attribute(Attribute::TARGET_CLASS)]
class DoctrineConfig
{
public function __construct(
/** @var 'single'|'flagbag' $type */
private string $type = 'single',
private ?BackedEnum $default = null,
private ?string $DBALTypeName = null,
/** @var class-string<AbstractEnumType> $DBALTypeParentClass */
private ?string $DBALTypeParentClass = null,
private bool $DBALTypeAutoConfigure = true,
) {}
}
and in elao config we add this:
elao_enum:
doctrine:
scan_namespaces_for_config:
- App\Namespace1
- App\SomeOtherNamespace\Enums
Edit: Ive added the $DBALTypeParentClass
which if null will default to checking elao.doctrine.enum_sql_declaration
. But it allows us to further extend TypesDumper
to support custom implementations of AbstractEnumType
The use-case is actually I think very common, as if you have a Form in Symfony, and you want a to populate a field, and have some value to represent the null DB value, then currently you cannot achieve this. So it will only be empty. See my example with membership type. I want null to represent no membership. But currently, the only way to have this nicely displayed inside Symfony form is to create a custom type and override the options.
I don't get this. Why would you need an enum case to represent the null
value? Use null
to represent null
.
There is no issue with exposing a null
value in your form type as part of the choices with its own label or using the placeholder
option.
Given the point 3 was about:
allow excluding some specific enum cases from the DB ENUM declaration
this looks even more specific to me, just to handle this 😅
this looks even more specific to me, just to handle this sweat_smile
yea, so I think we should implement sth like https://github.com/Elao/PhpEnums/issues/212#issuecomment-1356222111
this will allow everybody to make their own custom logic (with custom $DBALTypeParentClass
) and use auto-configuration from namespaces instead of explicit doctrine type listing in yaml config.
I have been using this library in my project, but for native SQL enums I decided to use my own implementation, as I was missing some features:
My question is - do you want me to port these features into this package?
See my implementation:
AbstractEnumType.php
DBALSQLEnumTypeInterface.php
DBALSQLEnumTypeDefaultForNullInterface.php
DBALSQLEnumTypeTrait.php
an example enum showcasing all the features:
the entity field then looks like this (notice how the DB value is nullable, but PHP is not, thanks to the fallback. The SQL declaration will be
ENUM('PAID','TRIAL') NULL
, the 'NONE' option is missing, if you assign it to your PHP instance, it will be converted to DBNULL
on insert/update):My services.yaml tags all AbstractEnumType instances:
and my Kernel takes care of auto-registration:
at this point I still need to create this boilerplate for every enum
but at least I dont have to register them then in
doctrine.yaml
. I am thinking about how to remove this requirement, maybe auto-generate the classes inside Kernel together with the auto-registration inTypeRegister
So are you interested in this feature, or should I leave this for everybody to implement on their own?
EDIT: credits to https://debest.fr/en/blog/php-8-1-enums-doctrine-and-symfony-enumtype as I took heavy inspiration from there with the tagging