-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native SQL enum improvements #212
Comments
Currently, you don't have to write anything in
Isn't it covered by the current ORM implementation when using
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. |
Yes, thats what I want
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.
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 |
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 WDYT?Edit: Ive added the |
I don't get this. Why would you need an enum case to represent the Given the point 3 was about:
this looks even more specific to me, just to handle this 😅 |
yea, so I think we should implement sth like #212 (comment) this will allow everybody to make their own custom logic (with custom |
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
The text was updated successfully, but these errors were encountered: