Doctrine DBAL

No way to get platform specific values from old schema to schema create sql

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0.4
  • Fix Version/s: None
  • Component/s: Schema Managers
  • 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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Eberlei added a comment -

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

Show
Benjamin Eberlei added a comment - 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
Hide
Permalink
Peter Jasiulewicz added a comment -

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

Show
Peter Jasiulewicz added a comment - 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
Hide
Permalink
Benjamin Eberlei added a comment - - edited

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

Show
Benjamin Eberlei added a comment - - edited 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).
Hide
Permalink
Peter Jasiulewicz added a comment - - edited

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

Show
Peter Jasiulewicz added a comment - - edited 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

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Peter Jasiulewicz
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: