Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-110

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

    Details

    • Type: Improvement Improvement
    • Status: 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

        Hide
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: