Closed michnovka closed 2 years ago
My idea for a PR was to make a new derived class AbstractSQLEnumType extends AbstractEnumType
. The main thing I dont know how to do is how to actually tag all the instances without having to insert stuff into services.yaml:
services:
_instanceof:
App\DBAL\AbstractEnumType:
tags: ['app.doctrine_enum_type']
I assume the actual part from Kernel.php could be moved into Bundle build()
function.
Hi @michnovka. Thank you for opening this feature request and sharing your code.
This was supported in the V1 of this package, but I didn't reintroduced this feature since the sql ENUM type is controversial, lacks support for proper diffs with the Doctrine schema diff tool when adding new cases and was never truely useful to us. See http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil
This is also the reason why the Doctrine team didn't used this type for their native support of PHP 8.1 enums.
Hi @ogizanagi , the 8 reasons article is from 2011. And its mostly incorrect for current versions of MySQL and MariaDB. But this is a preference choice, I like ENUMs in DB because they are easily readable and actually improve performance when used properly. There are cases where it makes really a lot of sense, such as ticket status (Open, In progress, Answered,...) or Continents. I know that this wont be implemented in Doctrine anytime soon because prejudice against them and also incompatibility with other DB engines, but I think we could extend this package to support it if anybody wants to actually use it.
@ogizanagi if you can help answer https://github.com/Elao/PhpEnums/issues/178#issuecomment-1057954105 I can try to make a working PR. Thanks
@michnovka : There is no need for derived classes nor tags for each of your enums types ; the bundle exposes a config allowing to declare the enums you'd like to store in a database and their format, then it generates and registers DBAL types for you.
The V1 had an SQL enum
type and base class used by the dumper. The V2 system is similar, but does not include the SQL enum type base class yet.
@ogizanagi I see, my solution allowed automatic type registration with Doctrine without the need of adding every single one into config file. I prefer this, because if I extend AbstractEnumType, then I definitely want it registered anyways.
@michnovka : Sure, but you need to extend a class, whereas the bundle config is generating these for you 😄 But your solution is fine in userland if you prefer to extend the base class rather than letting the config generate it 👌🏻 (but unnecessary in this bundle)
@ogizanagi so does the v2 bundle support type: enum or not? It seems that the removal of this is a set-back as it forces v2 to use varchar type always.
Not yet, but a PR is welcomed if you really wish this in the bundle config rather than using your solution in userland.
@ogizanagi ok, I will have a look. Id like to have this for the 2.0 final version. Will play around and let you know by Monday if I am able to do this, sounds good?
Sure 👍🏻
Lets continue discussion on the PR https://github.com/Elao/PhpEnums/pull/179
Hi, thanks so much for your package. I do not have time to actually make a PR at the moment, but I wanted to share what I did to support native MySQL ENUM types.
I have my own AbstractEnumType class:
When I make new enum like
I then make also a "wrapper" in DBAL folder:
This wrapper just returns the PHP enum which it links.
In
config/services.yaml
I put:and then in Kernel.php, I register all "wrapper" classes as valid types:
And thats it!. In Entity I use:
and the SQL generated by Doctrine migrations is:
Adding new native ENUM type consists of only creating the php enum, then making the wrapper class.
So I was thinking this might be interesting to extend in your own AbstractEnumType doctrine bundle, which now uses either
INT
orVARCHAR
. And if nothing else, it might help others who want native MySQL ENUMsThanks for your work!