[DBAL-110] No way to get platform specific values from old schema to schema create sql Created: 13/Apr/11  Updated: 13/Apr/11  Resolved: 13/Apr/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Peter Jasiulewicz Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

ubuntu 10.10 with php 5.3.3



 Description   

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-89



 Comments   
Comment by Benjamin Eberlei [ 13/Apr/11 ]

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

Comment by Peter Jasiulewicz [ 13/Apr/11 ]

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

Comment by Benjamin Eberlei [ 13/Apr/11 ]

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

Comment by Peter Jasiulewicz [ 13/Apr/11 ]

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

Generated at Fri Aug 29 14:06:12 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.