Skip to content

Loading…

DBAL-110: No way to get platform specific values from old schema to schema create sql #1039

Closed
doctrinebot opened this Issue · 5 comments

2 participants

@doctrinebot

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:

type declaration
<?php
use Doctrine\DBAL\Types\Type;
use Doctrine\DBAL\Platforms\AbstractPlatform;

class EnumType extends Type
{
const MYTYPE = 'Enum'; /
public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
{
return "ENUM(HERE IS THE PROBLEM)";
}

public function getName()
{
    return self::MYTYPE;
}

}
?>

db connection construction:
<?php
//...

\Doctrine\DBAL\Types\Type::addType('enum', 'CustomTypes\EnumType');
$conn->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'enum');

?>

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

related issues:
http://www.doctrine-project.org/jira/browse/[DBAL-4](http://www.doctrine-project.org/jira/browse/DBAL-4)
http://www.doctrine-project.org/jira/browse/[DBAL-89](http://www.doctrine-project.org/jira/browse/DBAL-89)

@doctrinebot

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:

http://www.doctrine-project.org/docs/orm/2.0/en/cookbook/mysql-enums.html

@doctrinebot

Issue was closed with resolution "Won't Fix"

@doctrinebot

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.

cheers,
Peter

@doctrinebot

Comment created by @beberlei:

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

@doctrinebot

Comment created by pejot:

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.

Cheers,
Peter

@beberlei beberlei was assigned by doctrinebot
@doctrinebot doctrinebot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.