Jira issue originally created by user pejot:
Even if I create custom types to support non-default types in Mysql (enum,set) I cant get the values from the schema manager to the type object due to encapsulation:
class EnumType extends Type
const MYTYPE = 'Enum'; /
public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
return "ENUM(HERE IS THE PROBLEM)";
public function getName()
db connection construction:
There is no way to create even an extension to better support mysql databases, and since its a pretty commonly used rdbms this issue lowers the value of Doctrine2 for mysql (since you get errors by going by the reference guide).
Comment created by @beberlei:
MySQL is a common database yes, people tend to use enums yes, but enums suck! They have tons of disadvantages that far outweight the simple benefit.
There is just no way to create a generic Enum type and never will be, you can only create one enum type per class of values as described here:
Issue was closed with resolution "Won't Fix"
Comment created by pejot:
Yes I understad that ENUMs aren't the best possible but since enums are internally represented as numbers not strings "Solution 1: Mapping to Varchars" makes it even worse and can result in making a database huge and slow, and botch solutions with "Solution 2: Defining a Type" pretty much renders DBAL schema tools and Migrations useless (which is the main part I wanted to use)
I'm not saying that you should follow bad practices but if Doctrine wats to be a mature tool it should be also be highly extensible. Currently it just lacks the capability to truly abstract the thing it was written to be an abstraction layer of.
Types are flyweight instances, this makes enum support impossible. So the choice for us was, have a highly customizable type system that doesnt support enums, or throw performance to hell. We picked one.
DBAL and Migrations firstly serve the ORM, then ship with their own features, SchemaTool was never designed to support every legacy application out there.
Btw: Mapping to varchars does not make the the database huge and slow, using columnDefinition this would still be a real ENUM. Just doctrine thinks its a string (aka varchar).
Thanks for expalining, still I wanted to use it mainly as a schema creation/comparator tool so this does'nt help much. Will migrate to doctrine when the project has matured.