[DMIG-40] DBAL Enum fields migration issue / PostgreSQL Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: postgresql, schematool
Environment:

PostgreSQL and migrations



 Description   

When using Custom Doctrine DBAL Enums the migration created using diff

works fine the first time.

However the next time it generates a SQL statement trying to change to field type to INT from integer; (Redundant)
and a truncated statement:

"ALTER schemaname.fieldname SET" .. And that's it.



 Comments   
Comment by Marco Pivetta [ 24/Apr/13 ]

This is a DBAL issue. Please verify the issue using the DBAL schema tools (latest master) only and eventually open a DBAL issue.





[DMIG-39] Issue when using serjal columns in PostgreSQL with Doctrine ORM Identity fields Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: postgresql, schematool
Environment:

PostgreSQL and migrations



 Description   

When using Doctrine ORM mapping fields like this:

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @ORM\SequenceGenerator(sequenceName="schemaname.tablename_id_seq", allocationSize=1, initialValue=1)
     */
    private $id;

It first creates the migration perfectly as a serial column with the correct schema.

However when making a new migration diff it generates DROP statements for every sequence for these id, so we have to remove them manually every time.



 Comments   
Comment by Marco Pivetta [ 24/Apr/13 ]

This is a DBAL problem.

Please verify this with the DBAL diff tools (latest master) only and eventually report a DBAL issue without involving migrations.





[DMIG-37] PostgreSQL generated SQL statements in migrations that use doublequotes create syntax errors in PHP Created: 28/Mar/13  Updated: 28/Mar/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: PostgreSQL, schematool
Environment:

PostgreSQL backend, using migration versions with field or schemanames that use reserved names.



 Description   

When using some reserved field names in PostgreSQL DBAL, the generated SQL statements will quote those field names. (Make a table with fieldname "left" for example)

When the migrationversion is generated, the doublequote is not escaped:

addSQL("ALTER table x add column "left" integer");

This does not compile of course, should be

addSQL("ALTER table x add column \"left\" integer");

Regards!






[DDC-2489] Missing semicolon in schema update tool, using dump-sql argument Created: 05/Jun/13  Updated: 12/Jun/13  Resolved: 12/Jun/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Robert-Jan Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: Cli, schematool


 Description   

When executing the schema-tool update script, using the --dump-sql argument (e.g. "app/console doctrine:schema:update --dump-sql" in a symfony2 project), the semicolon behind the last query is missing.



 Comments   
Comment by Guilherme Blanco [ 12/Jun/13 ]

Fixed in https://github.com/doctrine/doctrine2/commit/0d834d0bd4015de2c103a03592c1543399f1b363





[DDC-2469] SQLite handling for ENUM-Fields Created: 24/May/13  Updated: 24/May/13  Resolved: 24/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Andy Rosslau Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: query, schematool, sqlite


 Description   

SQLite doesn't support ENUMS!

But when I try create the schema of the following Entity Doctrine generates this "CREATE TABLE" - Statement:

CREATE TABLE Entity ([...] NOT NULL, taxation ENUM('incl', 'excl'), maxNumbe[...]
class Entity {
...

    /**
     * @var string
     *
     * @ORM\Column(type="string", columnDefinition="ENUM('incl', 'excl')")
     */
    private $taxation = self::TAXATION_INCL;

...
}

Produces this error:

SQLSTATE[HY000]: General error: 1 near "'incl'": syntax error'



 Comments   
Comment by Marco Pivetta [ 24/May/13 ]

Usage of

columnDefinition

in annotations or generally metadata mappings is all about vendor specific syntax. `columnDefinition` is designed to allow overriding the default ORM column generated DDL to build vendor specific syntax/types, therefore the issue is invalid





[DDC-2464] useless index for the middle table of many-to-many relationship Created: 21/May/13  Updated: 21/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: scourgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: ddl, schematool


 Description   

I have entity A and B, the relationship between A and B is many-to-many. which means Doctrine2 will generate a middle table called AB for me.

entity A:

class Station {
    /**
     * @ORM\ManyToMany(targetEntity="Fun", mappedBy="stations")
     */
    protected $funs;
}

entity B:

class Fun {
    /**
     * @ORM\ManyToMany(targetEntity="Station", inversedBy="funs")
     * @ORM\JoinTable(name="stations_have_funs")
     */
    protected $stations;
}

the schema of middle table stations_have_funs:

CREATE TABLE `stations_have_funs` (
  `fun_id` int(11) NOT NULL,
  `station_id` int(11) NOT NULL,
  PRIMARY KEY (`fun_id`,`station_id`),
  KEY `IDX_45C921911CA4BE49` (`fun_id`),
  KEY `IDX_45C9219121BDB235` (`station_id`),
  CONSTRAINT `FK_45C921911CA4BE49` FOREIGN KEY (`fun_id`) REFERENCES `funs` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_45C9219121BDB235` FOREIGN KEY (`station_id`) REFERENCES `stations` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

I noticed that there are 2 useless index(fun_id and station_id). Since fun_id and station_id are the primary key of this table. Do we really need 2 extra/duplicated index ?






[DDC-2425] Parent entity sometimes fails to load when validating/updating schema. Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Trivial
Reporter: Scott Gibson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: Cli, orm, schematool
Environment:

Debian 6.0.6 x64



 Description   

Should not have reported, was a stupid mistake on my part.






[DDC-2421] Many-To-Many relation creation failed when using non PK entity field Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: schematool
Environment:

Ubuntu linux 12.04, php 5.4.9



 Description   

Given these entities :

/**
 * Class Domain
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_domains")
 */
class Domain
{
    /**
     * @var string
     *
     * @ORM\Id
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';
}
/**
 * Class Web
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_webs",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="web_unique",columns={"name", "domain"})}
 * )
 */
class Web
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;
}
/**
 * Class WebsGroup
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_websgroups",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="websgroup_unique",columns={"name", "domain"})}
 * )
 */
class WebsGroup
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;

    /**
     * @var ArrayCollection
     *
     * @ORM\ManyToMany(targetEntity="Web", indexBy="id", fetch="EXTRA_LAZY")
     * @ORM\JoinTable(name="profils_websgroups_webs",
     *      joinColumns={
     * @ORM\JoinColumn(name="websgroup_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          },
     *      inverseJoinColumns={
     * @ORM\JoinColumn(name="web_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          }
     *      )
     */
    protected $webs;
}

I've got a domain, some web sites per domain and websgroups which group web sites. I want to be sure in my database that a web group from a domain D can contain only web sites from the very same domain but when calling the console tool for creating my schema it raise :

[Doctrine\ORM\ORMException]                                                                                                                                      
  Column name `domain` referenced for relation from Entity\WebsGroup towards Entity\Web does not exist. 

It's because domain is already an association to an entity which and is not part of the primary key.

I've quick fixed getDefiningClass from Doctrine\ORM\Tools\SchemaTool to make it work but i really don't know if it's the proper way :

    private function getDefiningClass($class, $referencedColumnName)
    {
        $referencedFieldName = $class->getFieldName($referencedColumnName);

        if ($class->hasField($referencedFieldName)) {
            return array($class, $referencedFieldName);
        } else if (in_array($referencedColumnName, $class->getIdentifierColumnNames())) {
            // it seems to be an entity as foreign key
            foreach ($class->getIdentifierFieldNames() as $fieldName) {
                if ($class->hasAssociation($fieldName) && $class->getSingleAssociationJoinColumnName($fieldName) == $referencedColumnName) {
                    return $this->getDefiningClass(
                        $this->em->getClassMetadata($class->associationMappings[$fieldName]['targetEntity']),
                        $class->getSingleAssociationReferencedJoinColumnName($fieldName)
                    );
                }
            }
        } else if (in_array($referencedColumnName, $class->getAssociationNames())) {
            return $this->getDefiningClass(
                $this->em->getClassMetadata($class->associationMappings[$referencedColumnName]['targetEntity']),
                $class->getSingleAssociationReferencedJoinColumnName($referencedColumnName)
            );
        }

        return null;
    }


 Comments   
Comment by Fabio B. Silva [ 29/Apr/13 ]

Bruno CHALOPIN Except for some CS this fix seems good.

If you have time you can send as pull request

Comment by Bruno CHALOPIN [ 30/Apr/13 ]

I've start making a PR and a test case but it is linked to http://www.doctrine-project.org/jira/browse/DDC-2413
I'm looking in making a proper fix to DDC-2413 first.

Comment by Benjamin Eberlei [ 01/May/13 ]

You cannot use a reference column that is not a primary key. Doctrine does not support this.





[DDC-2288] Schema Tool doesn't update collation on table level Created: 08/Feb/13  Updated: 08/Feb/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Rickard Andersson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collation, schematool


 Description   

In Symfony2, when updating the collation option of a table, the schema tool doesn't recognize the change:

Changing from:

 
* @ORM\Table()

To:

 
* @ORM\Table(options={"collate"="utf8_swedish_ci"})

Results in:

 
$ php app/console doctrine:schema:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.





[DDC-2238] doctrine:schema:update partially broken Created: 11/Jan/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Vogt Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: postgresql, schematool
Environment:

OS X 10.7.5
PHP 5.4.4
Postgres SQL 9.1.6

also confirmed on:
Linux (Debian testing, Kernel 2.6.32)
PHP 5.4.4
PostgreSQL 9.1.9
Doctrine 2.3.2


Attachments: Text File schemadiff.txt    
Issue Links:
Duplicate
duplicates DBAL-504 DBAL Enum fields migration issue / Po... Awaiting Feedback

 Description   

the app/console doctrine:schema:update command generates a seemingly random number of statements like these:

ALTER TABLE geodata ALTER humidity SET ;
ALTER TABLE geodata ALTER lake SET ;
ALTER TABLE message ALTER translate SET ;

which are obvious invalid SQL commands. The mappings are fine, validate and the application works just fine. Here's an example from the mapping files including two of the above statements:

<field name="coast" type="boolean"/>
<field name="lake" type="boolean"/>
<field name="river" type="boolean"/>
<field name="humidity" type="float"/>
<field name="biome" type="string"/>

I am using doctrine2-spatial as an extension for GIS information. This problem shows up both in entities using spatial data and entities not using spatial data.

I'll gladly help debug this, as right now I can't update my dev database with --force, I need to use --dump-sql and filter out the invalid lines.



 Comments   
Comment by Benjamin Eberlei [ 12/Jan/13 ]

Can you dump the SchemaDiff/ColumnDiff instances that are returned from lib/Doctrine/DBAL/Schema/Comparator.php?

Comment by Tom Vogt [ 12/Jan/13 ]

requested dump of SchemaDiff

Comment by Tom Vogt [ 12/Jan/13 ]

added in the file schemadiff.txt - I added this in Schematool.php - getUpdateSchemaSql():

$comparator = new Comparator();
$schemaDiff = $comparator->compare($fromSchema, $toSchema);
\Doctrine\Common\Util\Debug::dump($schemaDiff, 6);

if you need other output, just tell me what entity to dump and where. I'll be happy to help.

The file also contains the buggy update statements it creates towards the end. There's a few non-crucial bugs included, where it alters the geospatial columns to themselves (i.e. river.course already is a geometry/linestring). I don't worry about those because they don't break anything.

Comment by Tom Vogt [ 15/Apr/13 ]

Is there any update on this? I'm still having this issue, with many different entities, always the same problem, for example:

ALTER TABLE event ALTER priority SET ;

Which is an integer field on an entity that doesn't have any GIS elements, so I'm not even sure if it's caused by that anymore.

Comment by Benjamin Eberlei [ 01/May/13 ]

Tom Vogt I added a fix for PostgreSQL today, can you verify again if this works? Its included in the 2.3 branch.

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-504





[DDC-2135] Setting column defaults using options in the annotations causes redundant alter statements Created: 09/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Cory Comer Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: Cli, schematool


 Description   

When using the Column annotation on an entity and passing the options parameter to set a default value for a column, the doctrine cli will generate the alter statement every time the schema-tool is run.

This doesn't break the functionality of updating the schema using the cli but when you have multiple entities using default values in this manner it becomes cumbersome to investigate issues during updates that fail and you need to dump the generated sql to examine.

Use case: We have a number of entities that include 'boolean' flags. The data for these entities is inserted into the database through an integration process handled by another application. For all of the flags we want to set a default value of 0 to avoid having to modify the integration scripts when a new flag is added to an entity and the data is not available yet.

Example entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="example")
 */
class Example
{
    
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     */
    protected $id;
    
    /** @ORM\Column(type="integer", options={"default" = 0}) */
    protected $disabled;
    
}
$ php bin/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE example CHANGE disabled disabled TINYINT(1) DEFAULT '0' NOT NULL;

This alter statement is generated on every run of the schema-tool even though the schema has already been altered.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This is fixed for 2.3.4





[DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12  Updated: 08/Apr/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: SergSW Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, schematool

Attachments: File dump.sql     File SSWTestBundle.rar    

 Description   

I tried to create inheritance entities with save policy table per class.
Simple fileds was created normally, but a field with ManyToOne type was lost.

I had found a solution.

In Doctrine\ORM\Tools\SchemaTool
...

private function _gatherRelationsSql($class, $table, $schema)
    {
        foreach ($class->associationMappings as $fieldName => $mapping) {

           // if (isset($mapping['inherited'])) { // - old version

	/**
             * SSW
             * It's the solution
             */
	if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) {
                continue;
            }            

            $foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']);
...

But it was enough. In DQL query a simple query was made wrong.

I had found a solution again.
In Doctrine\ORM\Query\SqlWalker
...

public function walkSelectExpression($selectExpression)
...

                // original => if (isset($mapping['inherited'])){
                // It's the solution
                if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) {
                    $tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name'];
                } else {
                    $tableName = $class->table['name'];
                }
...

This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS.

I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS.

Sorry for my english.



 Comments   
Comment by Fabio B. Silva [ 05/Nov/12 ]

Hi SergSW

Could you try to write a failing test case ?

Thanks

Comment by SergSW [ 06/Nov/12 ]

SSW/TestBundle with the problem

Comment by SergSW [ 07/Nov/12 ]

I install the Symfony v2.0.18. and made small TestBundle.
I made schema database, by CLI "console doctrine:schema:update --force"
Result: Database schema updated successfully!
But I saw that I lost a field 'user_id' in a table 'AttachTree' (see Attach)

Comment by SergSW [ 07/Nov/12 ]

MySQL dump

Comment by Benjamin Eberlei [ 12/Nov/12 ]

Adjusted example formatting, don't apologize for your English, thanks for the report!

Comment by Benjamin Eberlei [ 24/Dec/12 ]

What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here.

Comment by Marco Pivetta [ 23/Jan/13 ]

SergSW news?





[DDC-2011] Schema tool fail to handle ManyToMany relation with an existing joinTable Created: 04/Sep/12  Updated: 09/Feb/13  Resolved: 09/Feb/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Erwan Richard Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 2
Labels: schematool


 Description   

The schemaTool fail with a Doctrine\DBAL\Schema\SchemaException when trying to handle ManyToMany relation with an existing joinTable.

My use case :

I'm using the Tree DoctrineExtension with the Closure strategy. It create a mapping between my Category entity and a CategoryClosure entity.

For conveniency, I've setup a ManyToMany relation between Category and Category with the CategoryClosure table as joinTable.

Doctrine ORM handle perfectly this case but the schema tool is failing with :
The table with name 'category_closure' already exists.



 Comments   
Comment by Alexander [ 09/Feb/13 ]

You can't expect the schematool to play nice if you use the table of an entity as m2m table.





[DBAL-483] default values make orm:validate-schema fail Created: 04/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Till Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: schematool
Environment:

MySQL, PHP 5.3, Doctrine 2.3



 Description   
% ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql                                                                                                  
ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL;
ALTER TABLE module ADD root_order INT DEFAULT 0 NOT NULL
% ./bin/doctrine.php --env=development orm:schema-tool:update --force
Updating database schema...
Database schema updated successfully! "2" queries were executed
% ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql                                                                                                  ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL;
ALTER TABLE module CHANGE root_order root_order INT DEFAULT 0 NOT NULL

My entities define these columns like this:

Group
    /**
     * @ORM\Column(name="active", type="boolean", options={"default":true})
     */
    private $active = true;
Module
    /**
     * @ORM\Column(name="root_order", type="integer", options={"default":0})
     */
    private $rootOrder = 0;


 Comments   
Comment by Felix Kaser [ 30/Apr/13 ]

We are having the same issue. Is there any workaround for this?

Comment by Felix Kaser [ 30/Apr/13 ]

I've investigated a bit and noticed several things:

  • looks like doctrine does not (officially?) support setting of default options in the annotation. It is recommended to use the instance default ($rootOrder = 0).
  • in the comparator class the Column->getDefault() is compared, but I found out that in one table (I guess the one from mysql) the default is set directly, in the other one (I guess the doctrine one generated from the annotations) the default is empty but the customSchemaOptions["default"] is set.

So based on this I would say:

  • the $column->getDefault needs to be checked against the other $column->getCustomSchemaOption("default") and vice versa

Please correct me if I'm wrong





[DBAL-482] SQL Server Schema Manager returns incorrect value for autoincrement on IDENTITY columns Created: 03/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2, 2.3, 2.3.3
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Minor
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: schematool, sqlserver, sqlsrv
Environment:

SQL Server



 Description   

When calculating table diffs, SQLServerSchemaManager returns column definitions for identity columns with _autoincrement set to FALSE.

This causes the schema update SQL generation to pump out a
ALTER TABLE x ALTER COLUMN id INT IDENTITY NOT NULL
for every single identity column in the schema.

The culprit is in DBAL\Schema\SQLServerSchemaManager, starting at line 43:

        $dbType = strtolower($tableColumn['TYPE_NAME']);
        $dbType = strtok($dbType, '(), ');

        $autoincrement = false;
        if (stripos($dbType, 'identity')) {
            $dbType = trim(str_ireplace('identity', '', $dbType));
            $autoincrement = true;
        }

When the column in question is an identity int column, the TYPE_NAME is "int identity". The second line of the snippet drops the "identity" signifier, causing the following lines that determine autoincrement to do nothing.

I simply moved the second line to below the autoincrement block ie:

        $dbType = strtolower($tableColumn['TYPE_NAME']);

        $autoincrement = false;
        if (stripos($dbType, 'identity')) {
            $dbType = trim(str_ireplace('identity', '', $dbType));
            $autoincrement = true;
        }

        $dbType = strtok($dbType, '(), ');

This change solves this issue for me, and as far as I can tell, has no other consequences.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed for 2.3.4 and was fixed for 2.4 in a different way already.





[DBAL-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13  Updated: 24/Apr/13

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql, schematool
Environment:

Windows & Linux



 Description   

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance.

If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail.

--------------------- UPDATE

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.



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

Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier?

Comment by jos de witte [ 24/Apr/13 ]

Dear Benjamin,

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.





[DBAL-420] Schema Drop SQL incorrect on PostgreSQL with entities with GeneratedValue(strategy="IDENTITY") Created: 23/Jan/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Adam Ashley Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: postgresql, schematool
Environment:

Symfony 2.1, PHP5.4, PostgreSQL 9.1 on Ubuntu 12.04



 Description   

This problem is probably related to #DBAL-54. However that was closed by the raiser as he changed his Entity model and it went away.

When schema drop is run the following error occurs:
Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP SEQUENCE radacct_radacctid_seq':

SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence radacct_radacctid_seq because other objects depend on it
DETAIL: default for table radacct column radacctid depends on sequence radacct_radacctid_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.

The source of this problem is the difference between strategy="IDENTITY" and strategy="SEQUENCE"

With SEQUENCE doctrine creates the table schema with field type BIGINT and no specified. It then creates a seperate sequence and as far as I can tell takes care of getting and inserting the next id number itself.

With IDENTITY doctrine creates the table schema with field type BIGSERIAL and no specified default. Now postgres automatically creates a sequence and creates the column with type BIGINT and sets the DEFAULT to the pgpsql statement required to get the nextval from the sequence.

At this point the two differently configured tables will work successfully and identically, except SEQUENCE tables will only get a correct new ID when run through the doctrine code while IDENTITY tables will get the correct new ID whenever an insert is done to the table.

Because in the case of an IDENTITY field postgresql creates the field with a default value refering to the sequence the sequence can not be deleted before the table reference is removed.

For my case I need the IDENTITY fields to work as we have a RADIUS server that needs to insert into one table which is managed and mapped to an entity in Doctrine.

Swapping the order of DROP TABLE and DROP SEQUENCE commands in Doctrine/DBAL/Schema/Visitor/DropSchemaSqlCollector.php in getQueries() line 159. Does not work as a quick fix. The following error occurs as the sequence is quite correctly be dropped along with the table.

Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP SEQUENCE radacct_radacctid_seq':

SQLSTATE[42P01]: Undefined table: 7 ERROR: sequence "radacct_radacctid_seq" does not exist



 Comments   
Comment by Adam Ashley [ 24/Jan/13 ]

This issue also appears to affect Doctrine_Migrations. Generated migrations try to drop and recreate automatically generated sequences associated with SERIAL fields making a mess of the database.

Comment by Benjamin Eberlei [ 22/Mar/13 ]

A related Github Pull-Request [GH-289] was opened
https://github.com/doctrine/dbal/pull/289

Comment by Adrien Crivelli [ 12/Apr/13 ]

@Adam Ashley, could you test whether https://github.com/doctrine/dbal/pull/289 solve your issue ?

Comment by Doctrine Bot [ 14/Apr/13 ]

A related Github Pull-Request [GH-289] was closed:
https://github.com/doctrine/dbal/pull/289





[DBAL-411] Schema updater breaks when using backticks in tablenames. Created: 08/Jan/13  Updated: 08/Jan/13

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Endaco Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Debian Linux 6.0, PHP 5.3.3, MySQL 5.1.63



 Description   

When using backticks around table-names (for example "`Order`"), the Doctrine schema update tool wants to recreate all foreign keys on every run.

This error was introduced in commit cb3ec49cb4401bd1c8be6ba9671f651802586eaf






[DBAL-367] Reverse engnering do not work with Oracle DB Created: 18/Oct/12  Updated: 23/Jan/13

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Zelenin Alexandr Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, schematool
Environment:

PHP 5.3.3-1ubuntu9.10 with Suhosin-Patch (cli) (built: Feb 11 2012 06:21:15)
oci8-1.4.7 as PHP extension builded from pecl repository with instantclient-basic-linux.x64-11.2.0.3.0.zip and instantclient-sdk-linux.x64-11.2.0.3.0.zip
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production



 Description   
$ doctrine orm:convert-mapping --filter="ms$ions" xml .

  [Doctrine\DBAL\DBALException]
  Unknown database type binary_float requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it.

cli-config.php:


use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;

require_once 'Doctrine/Common/ClassLoader.php';

define('APPLICATION_ENV', "development");
error_reporting(E_ALL);

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();

$config = new \Doctrine\ORM\Configuration();
$config->setProxyDir(__DIR__);
$config->setProxyNamespace('Proxies');

$config->setAutoGenerateProxyClasses((APPLICATION_ENV == "development"));

AnnotationRegistry::registerFile("Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php");
$reader = new AnnotationReader();
$driverImpl = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($reader, array(__DIR__ . "/../php/ru/niifhm/bioinformatics/biodb/model"));
$config->setMetadataDriverImpl($driverImpl);

if (APPLICATION_ENV == "development") {
    $cache = new \Doctrine\Common\Cache\ArrayCache();
} else {
    $cache = new \Doctrine\Common\Cache\ApcCache();
}

$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

$connectionOptions = array(
    'driver'   => 'oci8',
    'host'     => 'host.name',
    'dbname'   => 'db.name',
    'user'     => 'user.name',
    'password' => 'user.password'
);

$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);
$platform = $em->getConnection()->getDatabasePlatform();
$platform->registerDoctrineTypeMapping('enum', 'string');

$em->getConfiguration()->setMetadataDriverImpl(
    new \Doctrine\ORM\Mapping\Driver\DatabaseDriver(
        $em->getConnection()->getSchemaManager()
    )
);

$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
    'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
    'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));


 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Formatting





[DBAL-346] Generated schema fails on MySQL (BLOB/TEXT cant have DEFAULT value) Created: 19/Sep/12  Updated: 20/Sep/12  Resolved: 20/Sep/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2.2
Fix Version/s: 2.3
Security Level: All

Type: Bug Priority: Major
Reporter: Sascha Ahmann Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: Cli, schematool
Environment:

Symfony 2.1.x (dev/master), Doctrine 2.2.3, MySQL 5.5.x



 Description   

In my symfony 2.1 project i was including JMSPaymentCoreBundle and did the vanilla installation.

After that i ran

php app/console doctrine:schema:update --dump-sql
php app/console doctrine:schema:update --force

A lot of schema updates were done. I ran it again, and two schema updates were still showing up.
Running the command again, and they still show up.

I then tried to run the two schema updates against my database and MySQL complains with the following error:

Error: 1101 - BLOB/TEXT column 'extended_data' can't have a default value

According to the Documentation BLOB/TEXT indeed cannot have default values. I am not sure why Doctrine thinks it has to set this default value.

The statements look like this:

sascha@debian:/var/www/myproject/Symfony$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE payment_instructions CHANGE extended_data extended_data LONGTEXT NOT NULL COMMENT '(DC2Type:extended_payment_data)';
ALTER TABLE financial_transactions CHANGE extended_data extended_data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:extended_payment_data)'

I already reported this problem in the JMSPaymentCoreBundle Issue Queue where i then was referred to over here.

Also, i am not sure if Doctrine DBAL is the best match for this issue, so if it is wrong please move it to the right project issue queue.

Thank you very much and best of Regards!
Sascha






Generated at Wed Jun 19 09:25:32 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.