[DBAL-1139] [GH-793] fix SequenceName for Oracle Created: 30/Jan/15  Updated: 30/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Gemorroj:

Url: https://github.com/doctrine/dbal/pull/793

Message:

I want to use a new feature, specify the oracle IDENITY generator (http://www.doctrine-project.org/jira/browse/DDC-2875) . But after inserting a new row, doctrine causes the wrong sequence to find out the id of the inserted row. My problem is solved by adding processing the column name.






[DBAL-1138] [GH-792] getSQLForJoins - infinite recursion if join alias is not unique Created: 30/Jan/15  Updated: 30/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jarekj:

Url: https://github.com/doctrine/dbal/pull/792

Message:

fix for exception message






[DBAL-1136] [GH-791] Update QueryBuilderTest.php Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Reference
relates to DBAL-1137 Infinite recursion on non-unique tabl... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of jarekj:

Url: https://github.com/doctrine/dbal/pull/791

Message:

test shows out of memory



 Comments   
Comment by Doctrine Bot [ 30/Jan/15 ]

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





[DBAL-1137] Infinite recursion on non-unique table/join alias in QueryBuilder Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Reference
is referenced by DBAL-1136 [GH-791] Update QueryBuilderTest.php Resolved

 Description   

The QueryBuilder runs into an infinite recursion when using duplicate table aliases for table and/or join clauses:

$qb->select('a.id, b.id')
    ->from('table_a', 'a')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('b', 'table_a', 'a', 'a.fk_b = b.id');

Non-unique table aliases should be detected and an appropriate exception should be thrown instead.






[DBAL-1135] [GH-789] Fix when finding arrays of binary strings Created: 28/Jan/15  Updated: 29/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.4, 2.5, 2.6
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: array, binary, expansion, lob, parameter, sqlparserutils


 Description   

This issue is created automatically through a Github pull request on behalf of cerealean:

Url: https://github.com/doctrine/dbal/pull/789

Message:

What the problem was
-------------------------
When using the ORM findBy() method to select data in a binary column (compared against an array of binary strings), I would get exceptions. Code example:

```php
/**

  • @param string[] $email_addresses Encrypted email addresses
  • @return \Project\Entity\EmailAddresses[]
    */
    public function retrieveEmailAddressEntities(array $email_addresses) { return $this->repository->findBy(['EmailAddress' => $email_addresses]); }

    ```

When I would only search for one binary string, however, everything would work correctly. I noticed I was getting a PHP Notice for array to string conversion in my error log:

```
PHP Notice: Array to string conversion in/var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 91
```

In my MySQL table, the column is a varbinary(255) and the ORM entity was marked as type "binary".

How I fixed
--------------
I noticed that the `$type` in `SQLParserUtils::expandListParameters` was marking the type as 103. When this method was checking array types, it was not checking for binary strings. By simply adding the extra check for type 103 in this method, everything started working properly. Line comments below.

Extra
------
This worked to fix it for me and I haven't noticed any side effects of this, however I have not extensively tested all features. If there are any problems with this please let me know.

Specific file commit comments:
--------------------------------------
Connection.php

  • Added constant PARAM_LOB_ARRAY for binary

SQLParserUtils.php

  • Added check to see if the array type is binary
  • Changed the way that the foreach checked if the type was not equal to int, string, or binary





[DBAL-1058] It seems that MSSQL syntax was changed Created: 05/Dec/14  Updated: 29/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.4.4, 2.6, 2.5.1

Type: Bug Priority: Blocker
Reporter: man4red Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal, sqlserver

Issue Links:
Reference
is referenced by DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Resolved
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Resolved

 Description   

I'm using dblib, MSSQL (2012).
So, problem is here:

doctrine-module orm:schema-tool:update --dump-sql

Doctrine\DBAL\Driver\PDOException: SQLSTATE[HY000]: General error: 20018 Invalid object name 'SYS.SCHEMAS'. [20018] (severity 16) [SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')] in /var/www/domains/internal.dc.hayas.ru/data/partners.zf2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 106

So it seems, that problems is here:

Doctrine\DBAL\Platforms\SQLServerPlatform.php
At Line 1036

    public function getListNamespacesSQL()
    {
        return "SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

SQL Server >= 2005 uses sys.schemas (lowercase)

Maybe need to add to SQLServer2005Platform.php

SELECT name FROM sys.schemas ...

and also at line 1028 SQLServerPlatform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

add to SQLServer2005Platform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM sys.databases';
    }


 Comments   
Comment by Steve Müller [ 05/Dec/14 ]

man4red thanks for reporting. I'll have a look at it this evening. Weird that the functional tests pass though in my setup :S

Comment by Marco Pivetta [ 05/Dec/14 ]

Steve Müller please note that he is using dblib, which (afaik) we do not officially support.

Comment by man4red [ 05/Dec/14 ]

I've checked by direct query to SQL via SQL Management Studio.
Got multiple servers with a diffirent versions.

Here some test

QUERY:

 SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys') 

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) FAIL
11.0.5058 (SQL Server 2012) FAIL

QUERY:

SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

I've tested on 5 servers 11.0.5058 (SQL Server 2012).
QUERY:

SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

Failed on each of them

Other tests:

QUERY:

SELECT * FROM SYS.DATABASES

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

QUERY:

SELECT * FROM sys.databases

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

by the way - is it neccessary to query * from SYS.DATABASES ?

Doctrine\DBAL\Platforms\SQLServerPlatform.php

Line 1030

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

Maybe need to query only names? (name field)
Just asking

Comment by man4red [ 05/Dec/14 ]

According to tests I've added next code to SQLServer2008Platform.php

    /**
     * {@inheritDoc}
     */
    public function getListNamespacesSQL()
    {
        return "SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

And modified my ZF2 application doctrine config config/autoload/doctrine.local.php (platform added):

return array(
    'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'class to work with dblib',
                'params' => array(
                    'host' => 'hostname',
                    'port' => 1433,
                    'user' => 'user',
                    'password' => 'pass',
                    'dbname' => 'database',
                    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()
                )
            )
        )
    )
);

Now I've got no issues with MSSQL 2012
I hope my fix was correct

Comment by Steve Müller [ 05/Dec/14 ]

Patch provided: https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by man4red [ 05/Dec/14 ]

Dear friends,

I'm new here, and I don't know how all this works here, but can you help me?
As always when one bug fixed - another two produced

Now I've got another problem.
ZendDeveloperTool throws Exception

Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDO instances'

of course because of my

    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()

ok... my mistake

let's fix it in ZF2 way

    'platform' => 'Doctrine\DBAL\Platforms\SQLServer2012Platform'

Now we got another exception:

Doctrine\DBAL\DBALException: Invalid 'platform' option specified, need to give an instance of \Doctrine\DBAL\Platforms\AbstractPlatform.

let's look to doctrine\dbal\lib\Doctrine\DBAL\Connection.php Line: 387

    private function detectDatabasePlatform()
    {
        ...
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }
        ...
    }

So my question is

Can we implemet a feature and change this

    private function detectDatabasePlatform()
    {
        if ( ! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

to this (or similar)

    private function detectDatabasePlatform()
    {
        if (! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } elseif (is_subclass_of($this->_params['platform'], 'Doctrine\DBAL\Platforms\AbstractPlatform')) {
            $this->platform = new $this->_params['platform']();
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

or this problem is only mine and I need to fix it by my self and to write some forks/mods etc?

Thx for your help anyway

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red that seems to be related with DBAL-1057 - I'll mark this issue as resolved.

Comment by man4red [ 05/Dec/14 ]

Marco Pivetta, thx! Is there planned some big reworking of this section, am I right?
Am I need to post my last comment to DBAL-1057 thread?

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red this section needs some work for 2.5.1, yes. As for posting to DBAL-1057, please do, but only the bits that may be relevant and that you feel that add up to the discussion without cluttering it.

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Marco Pivetta [ 12/Jan/15 ]

Fixed in DBAL-1060

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DBAL-1129] [GH-783] Fixes issue (DBAL-1057) use default platform when not connected Created: 23/Jan/15  Updated: 29/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of weaverryan:

Url: https://github.com/doctrine/dbal/pull/783

Message:

Hi guys!

This is a fix for http://www.doctrine-project.org/jira/browse/DBAL-1057. It leaves the ability to set the platform and platform version from sha: 3176f51d1426022d305c6531a9b9bc93a868bddd, but does not try to connect if we're not already connected. This is consistent with the previous behavior (again see the linked sha) - before there was never a connection made to determine the platform.

The alternate solution is to connect, but surround this by a try-catch (`PDOException`, `DriverException`, `Exception`?) and return `null`. in case we have some situation where the database isn't created or the connection information is wrong.

I know this issue is causing a lot of problems around my world (I ran into myself yesterday), so thanks in advance for the attention.

Thanks!



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DBAL-1115] [GH-773] Fix quoted identifiers for database creation SQL on SQL Anywhere Created: 13/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create-database, ddl, drop-database, identifier, quotation, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/773

Message:

In SQL Anywhere the statements `CREATE DATABASE`, `DROP DATABASE`, `START DATABASE`, `STOP DATABASE` always take unquoted identifiers.
This PR ensures given identifiers are always passed unquoted to the generated SQL.
This issue was discovered by using DoctrineBundle's `database:create` and `database:drop` commands which always quote the database identifiers.

```bash
$ php app/console doctrine:database:create
Could not create database for connection named "symfony"
An exception occurred while executing 'START DATABASE '"symfony"' AUTOSTOP OFF':

SQLSTATE [00000] [-82] Angegebene Datenbank konnte nicht gestartet werden: Illegal character in database alias.
```



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DBAL-1133] [GH-787] Add left-over console file Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: binary, composer, console, tools


 Description   

This issue is created automatically through a Github pull request on behalf of t0xicCode:

Url: https://github.com/doctrine/dbal/pull/787

Message:

`bin/doctrine-dbal` includes `bin/doctrine-dbal.php`, but the later is not symlinked to the `vendor/bin` directory of projects as it is not declared in composer.json. This PR declares the file as a vendor binary.



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DBAL-1134] [GH-788] Improved failure resilience for array type Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: array, array-type, exceptions, type, type-conversion, type-safety, validator


 Description   

This issue is created automatically through a Github pull request on behalf of garwat82:

Url: https://github.com/doctrine/dbal/pull/788

Message:

The array type is the only one that throws an error if the value can't be decoded and that causes problems if the database column is empty or invalid. The patch adjusts the behavior to the rest of the implemented types.



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DBAL-464] MySQL fails when try to drop a primary index with Auto Increment Created: 14/Mar/13  Updated: 26/Jan/15  Resolved: 18/Dec/13

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

Type: Bug Priority: Minor
Reporter: Julien Rosset Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux (ubuntu), PHP 5.3.10, MySQL 5.5.29, Symfony2



 Description   

When an update of schema tries to drop a primary key with "auto increment" property (example : @ORM\GeneratedValue(strategy="AUTO")), the execution will fail : it say :
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE odesadicola DROP PRIMARY KEY':

SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key

Apparently, this error occurs because Doctrine try to execute a "drop primary key" on a table and the resulting column of old primary key will be "auto increment".

The answer is to remove "auto increment" attribut of primary key column juste before try to drop the primary key itself.



 Comments   
Comment by Andreas Goetz [ 25/Jan/15 ]

I'm still seeing this problem in 2.5.1 on mysql. Any advice?

Comment by Steve Müller [ 26/Jan/15 ]

It has been fixed and the test case here is also passing: https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/Functional/Schema/MySqlSchemaManagerTest.php#L121-L145

Please provide more context and information to make the error reproducable. Thanks.

Comment by Andreas Goetz [ 26/Jan/15 ]

Only a partial fix, see https://github.com/andig/dbal/commit/bd07dced2bf4638d6e12c23a92b452922e8f173b

Comment by Andreas Goetz [ 26/Jan/15 ]

Sorry, I've meant https://github.com/doctrine/dbal/pull/786





[DBAL-1132] [GH-786] Fix removing autoincrement column from a primary key Created: 26/Jan/15  Updated: 26/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of andig:

Url: https://github.com/doctrine/dbal/pull/786

Message:

https://github.com/doctrine/dbal/pull/430 is only a partial fix for DBAL-464. This adds treating autoincrement columns that get removed when altering a primary key.






[DBAL-903] php app/console doctrine:migration:diff generates redundant sql queries for postgres Created: 12/May/14  Updated: 26/Jan/15

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

Type: Bug Priority: Minor
Reporter: Hanov Ruslan Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: None


 Description   

php app/console doctrine:migration:diff

generates redundant sql queries for postgres

symfony 2.4.2,
postgres 9.3
doctrine/orm: ~2.2,>=2.2.3
doctrine/doctrine-bundle: 1.2.*
doctrine/migrations: dev-master
doctrine/doctrine-migrations-bundle: dev-master

    public function up(Schema $schema)
    {
      
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("DROP SEQUENCE acl_classes_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_security_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_object_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_entries_id_seq1 CASCADE");
    }

    public function down(Schema $schema)
    {
       
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
    }


 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Doctrine ORM 2.2.x is EOL and won't receive any updates anymore. Please consider upgrading to at least 2.3 and reopen if the issue is still there. There have been a LOT of fixes to platforms' SQL generation since 2.2.x.
Also if you still encounter the issue, please add your mapping information, otherwise it will be hard to rack the issue down.

Comment by Steve Müller [ 26/Oct/14 ]

Oh sorry read your ORM version constraint wrong. Reopening. Please can you give the exact DBAL version you are using and mapping information? Thanks.

Comment by Timur Ramazanov [ 26/Jan/15 ]

Vote for this issue.

postgres: 9.3,
doctrine/orm: "~2.2,>=2.2.3",
doctrine/doctrine-bundle: "~1.3",
doctrine/migrations": "1.0.x-dev",
doctrine/doctrine-migrations-bundle": "2.1.x-dev"





[DBAL-1131] [GH-785] Handle default values for datetime/datetimetz columns in PostgreSQL Created: 25/Jan/15  Updated: 25/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/785

Message:

(This was originally in #670 but am re-submitting due to a busted merge)

When dealing with legacy schema it would be nice to be able to map default values and not have the schema spit out ALTER statements each time. This works correctly today for basic integer and string columns, but does not handle columns with special types such as boolean or datetime.

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

`test_column | timestamp with time zone | not null default now()`

However, repeating the same schema generation will result in the same ALTER statement each time, because it will always detect that the default value has changed. The same is true for boolean columns.

This simple change prevents this situation from happening and correctly detects that the column default has not changed. It is specific to PostgreSQL.






[DBAL-983] [GH-670] Handle default values for boolean, datetime, and datetimetz columns in PostgreSQL Created: 27/Aug/14  Updated: 25/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: date, datetime, postgresql, type


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/670

Message:

When dealing with legacy schema it would be nice to be able to map default values and not have the schema spit out `ALTER` statements each time. This works correctly today for basic integer and string columns, but does not handle columns with special types such as `boolean` or `datetime`.

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

`test_column | timestamp with time zone | not null default now()`

However, repeating the same schema generation will result in the same `ALTER` statement each time, because it will always detect that the default value has changed. The same is true for boolean columns.

This simple change prevents this situation from happening and correctly detects that the column default has not changed. It is specific to PostgreSQL.



 Comments   
Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DBAL-1128] [GH-782] Fix: SQLite offset with no limit support Created: 23/Jan/15  Updated: 24/Jan/15  Resolved: 24/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.5, 2.4.4, 2.5.1
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: limit, offset, paginator, select, sqlite, syntax


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/782

Message:

Required for doctrine/doctrine2#1280

This just slipped through.

Should be merged into 2.4, 2.5 and 2.6



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DBAL-1130] [GH-784] "Breaking" a test temporarily to show that it's not doing what is expect... Created: 23/Jan/15  Updated: 23/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of weaverryan:

Url: https://github.com/doctrine/dbal/pull/784

Message:

Hi guys!

This is not meant to be merged, at least not yet. The test added in #691 is flawed. It's failing NOT because there is an exception when trying to use a closed connection (in fact, if the connection is closed, it simply re-opens), but instead, the exception is:

>
Access denied for user 'root'@'localhost' (using password: YES)

The tests should show this. The reason is that we're using connection parameters at the top of this class (https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/ConnectionTest.php#L19) that, until now, were never used to actually connect to the database. But now, they are being used to connect to the database, but they're incorrect - they should be pulling from `TestUtil`.

So, this test needs to be fixed or removed.

Thanks!






[DBAL-1127] [GH-781] Call detectDatabasePlatform only once Created: 22/Jan/15  Updated: 22/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of rosier:

Url: https://github.com/doctrine/dbal/pull/781

Message:

Database platform detection is triggered twice if `Doctrine/DBAL/Connection::getDatabasePlatform()` is called before `Doctrine/DBAL/Connection::connect()`






[DBAL-1125] [GH-780] Add autoload to composer.json Created: 20/Jan/15  Updated: 21/Jan/15  Resolved: 21/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: autoloader, composer


 Description   

This issue is created automatically through a Github pull request on behalf of pgddevil:

Url: https://github.com/doctrine/dbal/pull/780

Message:



 Comments   
Comment by Doctrine Bot [ 21/Jan/15 ]

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





[DBAL-1126] Amazon SimpleDB/DynamoDB Support Created: 21/Jan/15  Updated: 21/Jan/15

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

Type: New Feature Priority: Major
Reporter: Bo Zhou Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello

Would you please to tell me if there is any plan to support ORM for Amazon SimpleDB/DynamoDB ? Thanks !



 Comments   
Comment by Marco Pivetta [ 21/Jan/15 ]

I don't see join support in AWS DynamoDB, therefore I don't see how support from our side can be provided





[DBAL-1124] License notes whis porting of classes Created: 19/Jan/15  Updated: 20/Jan/15

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

Type: Task Priority: Minor
Reporter: Vladimir Khramov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I ported SQLParserUtils to zephir language for Phalcon 2 framework and used modified php tests for this class.

Phalcon licended by New BSD. Now I used default phalcon templates for files:
https://github.com/quantum13/cphalcon/blob/bind_array/phalcon/db/utils/sqlparser.zep
https://github.com/quantum13/cphalcon/blob/bind_array/tests/unit/Phalcon/Db/Utils/SQLParserTest.php

Please say, what I should to add to this files. Should I to add MIT license text to list of phalcon licenses?



 Comments   
Comment by Marco Pivetta [ 19/Jan/15 ]

The license clearly states:

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

You need to copy the LICENSE from https://github.com/doctrine/doctrine2/blob/2418f8f5e661c653e4b13cd433d569ece7318f62/LICENSE at least into the derived files, and keep a reference to the original author there.

Other than that, MIT, BSD-2-Clause and BSD-3-Clause are compatible.





[DBAL-1120] [GH-776] Don't throw an exception during database platform guessing Created: 16/Jan/15  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: connection, detection, platform


 Description   

This issue is created automatically through a Github pull request on behalf of rosier:

Url: https://github.com/doctrine/dbal/pull/776

Message:

Fallback to the "default" database platform if connecting to the database fails.

Fixes https://github.com/symfony/symfony-standard/issues/748



 Comments   
Comment by Doctrine Bot [ 16/Jan/15 ]

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





[DBAL-1123] [GH-779] Initialize database schema only once per PHPUnit run Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: performance, phpunit, testsuite


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/779

Message:

Currently the PHPUnit test suite recreates the database schema on each invocation of `TestUtil::getConnection()` which is highly inefficient and costly concerning performance, especially on platforms where schema recreation consumes a lot of time.
With this patch the database schema is initilaized once per PHPUnit run, increasing overall test suite runtime significantly.
For example using SQL Anywhere, database creation takes about 4-5 seconds which results in a complete test suite runtime of several minutes. With this patch the complete test suite runs in about 12-15 seconds *!*.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1122] [GH-778] Cleanup PHPUnit test suite bootstrap Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: bootstrap, phpunit, testing


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/778

Message:

Removes `require_once` statements leftovers in PHPUnit test classes in favour of properly bootstrapping via PHPUnit config files.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1121] [GH-777] Make host and server connection parameters optional for sqlanywhere driver Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection, driver, host, parameters, server, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/777

Message:

This patch makes it possible to connect to a SQL Anywhere database without having to specify `host` and/or `server` connection parameter.
The original assumption that the `server` parameter is necessary to connect to the database was wrong. It is only required if the host is running multiple named server instances and a specific instance should be connected to.
Also if the `host` parameter is not specified, it will default to `localhost` now.
The `LINKS` DSN parameter was replaced by the simpler and encouraged `HOST` parameter as the `LINKS` parameter is only required if you want to pass specific TCP/IP options.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1057] Connection is not lazy anymore when guessing the platform is necessary Created: 05/Dec/14  Updated: 16/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 8
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-1067 mysql: selecting db issue Resolved
Reference
is referenced by DDC-3475 Avoid db connection in constructor Open

 Description   

In DBAL 2.5, many driver can rely on different versions of the platform. Unless the version is explicitly provided, the driver will guess it at instantiation time, killing the lazyness of the connection.
This is a critical issue in any context using DI as it means that injecting the connection into anything else will connect to the server.



 Comments   
Comment by Christophe Coevoet [ 05/Dec/14 ]

Actually, the Connection class itself defers the guessing until the first time the platform is accessed. But many places in DBAL and in the ORM are retrieving the platform and storing it in a property of the class at instantiation time to avoid method calls when they need to access the platform. So this might be much harder to fix

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet Can we analyze the use cases where retrieving the platform is necessary before actually connecting? I only know the custom type registering so far... Maybe we can defer that somehow?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller the issue is that many places in DBAL and the ORM are retrieving the connection before they use it. the Connection class itself in DBAL is already deferring the guessing

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet I know that. The question is WHY do those defered connections need to access Connection::getDatabasePlatform() without connecting? What are the use cases?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller The issue is that all those objects are calling $connection->getDatabasePlatform() in their own constructor to store a reference to it for faster access later (no more method calls). This means that *instantiating* the ORM (or some parts of DBAL) triggers the platform guessing, which connects to the DB. This breaks the lazyness and hurts DI contexts (maybe the ORM will not even be used in this process, but it was instantiated because of being a dependency in a complex object graph).

Comment by Christophe Coevoet [ 05/Dec/14 ]

and the issue is precisely that all these parts of Doctrine are *not* deferring the retrieval of the platform.

Comment by Steffen Brem [ 07/Dec/14 ]

This is causing a lot of issues when using CI servers. Where it is very important that those things are lazy, since you do not have the database configured on most applications that build on a CI server.

Comment by Craig Heydenburg [ 01/Jan/15 ]

This is also an issue for the project I am working as I am trying to use Symfony to to generate forms and so on in order to install the project. sForms and the main project's front controller trigger DI events and trigger this error. The workaround mentioned here (https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-65771528) fixes the problem but this cannot be a long term solution. I look forward to the fix for this issue.

Comment by Alan Hartless [ 07/Jan/15 ]

I have the same issue as Craig. This poses a major hassle for applications that have an installer UI. We have a Symfony based application that gives the user options to configure the database such as driver, table, credentials, etc. Then the application will make a dynamic connection to check database, install data, etc. Eventually Symfony's cache is cleared to use the new credentials post install.

Because of this, the installer fails out of the box since it can't connect to the server.

We can't use the work around as mentioned above because of giving the option to choose what driver to use in the installer.

Thanks,
Alan

Comment by Craig Heydenburg [ 14/Jan/15 ]

Tried an experiment today. As noted in the workaround you can set the server_version: 5.1 (or whatever your version is).

Well, my version is 5.5 so I originally used that. Today I tried 5 and 52 and 1 and they all worked!

so it seems that the actual version doesn't matter (at least when I need them, which is before I've actually set up the DB credentials) as long is there is some value.

Comment by Steve Müller [ 15/Jan/15 ]

Craig Heydenburg this is expected behaviour. You can theoretically specify any value you want, DBAL will try to find the appropriate platform for you by the specified version via version compare.
See the example for PostgreSQL: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php#L97-L119
As soon as the specified value/version does not match a specific platform version, DBAL will always fallback to the "default" platform (the one that was chosen by default prior 2.5).
Once the serverVersion parameter is set, auto detection of the proper platform is always bypassed.

Comment by Jan Rosier [ 16/Jan/15 ]

Doctrine now also throws a connection exception when it tries to detect the database platform, but can't make a connection to the server. Even if the connection isn't really used.

I think it would be better to do a fallback to the "default" platform in that case and only throw an connection exception if the connection is required for something else than guessing the platform.

For example if you haven't set up the DB credentials yet and only call Doctrine\DBAL\Connection::getDatabasePlatform() you get the "default" platform.





[DBAL-1119] [GH-775] fix diffColumn in text length is different Created: 16/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of arima-ryunosuke:

Url: https://github.com/doctrine/dbal/pull/775

Message:

Because mysql has multiple TEXT types.

```
$column1 = new Column('clobfield1', Type::getType('text'), array('Length' => 128));
$column2 = new Column('clobfield1', Type::getType('text'), array('Length' => 65536));

$platform = new MySqlPlatform();
var_dump($platform->getClobTypeDeclarationSQL($column1->toArray()));// this is "TINYTEXT"
var_dump($platform->getClobTypeDeclarationSQL($column2->toArray()));// this is "MEDIUMTEXT"

$c = new Comparator();
var_dump($c->diffColumn($column1, $column2));// this is empty!
```



 Comments   
Comment by Doctrine Bot [ 16/Jan/15 ]

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

Comment by Doctrine Bot [ 16/Jan/15 ]

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





[DBAL-1118] Schema does not create autoincrement keys for MySQL Created: 15/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

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

Type: Bug Priority: Major
Reporter: Gabriel Birke Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

There seems to be no way to generate an autoincrementing primary key for MySQL with the the Schema class:

    $schema = new \Doctrine\DBAL\Schema\Schema;
    $table = $schema->createTable("foo");
    $table->addColumn('id', "integer", array("unsigned" => true);
    $table->setPrimaryKey(array("id"));
    $connectionParams = ["url" => "mysql://user:password@localhost/mydb"];
    $conn = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
    $queries = $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
    foreach ($queries as $q) {
            echo "$q\n";
            $conn->exec($q);
     }

creates a table without autoincrementing keys. The SQL generated is as follows:

CREATE TABLE foo (id INT UNSIGNED NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

When I change the definition to

$table->addColumn('id', "integer", array("unsigned" => true, "autoincrement" => true));

instead, I get the following error:

SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key.

and the following SQL:

CREATE TABLE foo (id INT UNSIGNED AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

If there is a way to achieve this, please update the documentation.



 Comments   
Comment by Steve Müller [ 15/Jan/15 ]

This looks like a usage error. Can you please provide more information on how you create the table in the database? Those code snippets do show how you actually create the table in the database. Maybe also the executed SQL would help.

Comment by Gabriel Birke [ 15/Jan/15 ]

I've updated the code example. I can run the whole example locally and it generates a table "foo" with column "id" that is a primary key without autoincrement. Tried on two computers. Probably a usage error, but what am I missing?

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke thanks for the additional information. However we also need the exact SQL statements that are generated by $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
Thank you. Also are you using DBAL 2.5.1 (according to the ticket information)?

Comment by Steve Müller [ 16/Jan/15 ]

And please remember to gather the SQL when using autoincrement => true

Comment by Gabriel Birke [ 16/Jan/15 ]

Well, at least for my small test script it works now (it did not yesterday, but I don't know why).

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke both SQL statements are totally valid and expected to be generated this way. Also tried them out locally and they work perfectly. I guess it was a usage mistake somehow then. If it's working for you now I would like to close the issue

Comment by Steve Müller [ 16/Jan/15 ]

Ah you did already, thanks!





[DBAL-1117] id names not quoted on create in MySQL Created: 14/Jan/15  Updated: 14/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Anders Jenbo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 14.04, MySQL 5.5, MySQLi driver



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because group is a key word.
<id name="group" association-key="true"/>






[DBAL-504] DBAL Enum fields migration issue / PostgreSQL Created: 24/Apr/13  Updated: 14/Jan/15  Resolved: 03/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

postgresql


Issue Links:
Duplicate
is duplicated by DDC-2238 doctrine:schema:update partially broken Resolved
Reference
relates to DBAL-4 missing column type "enum" Resolved

 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 Tom Vogt [ 01/May/13 ]

Doesn't only happen on Enums. I don't use any enums and I have this problem. I use a couple of geo (postGIS) fields (point, linestring, polygon) as well as array fields, so either or all of those might be causing it, too.

Comment by Benjamin Eberlei [ 04/May/13 ]

We did some changes for PostgreSQL column diffs lately, can you verify this bug still exists on the 2.3 Branch of DBAL?

Comment by Tom Vogt [ 06/May/13 ]

I'm running this on Symfony2 with this composer.json config:

"doctrine/orm": "2.3.*",
"doctrine/doctrine-bundle": ">=2.1",

and I'm still getting this issue today.

Comment by Steve Müller [ 29/Dec/13 ]

jos de witte Tom Vogt The truncated statement is most probably related to the column default value issue on PostgreSQL which should be fixed in this commit: https://github.com/doctrine/dbal/commit/8fe741053849afadef12b8bef1cc3203966ef78f
Can you please again check if this still exists in the current master branch.
If it still exists please provide your mapping information and the changes that cause wrong SQL. Thank you.

Comment by Tom Vogt [ 30/Dec/13 ]

Quick check after updating (composer says my versions are now:

  • Updating doctrine/doctrine-bundle dev-master (2ed4639 => c65e5a2)
    Checking out c65e5a21d1db794511d11fe28918f41bd6072f8f
  • Updating doctrine/dbal 2.3.x-dev (59c310b => 907f30d)
    Checking out 907f30dec77a9e83fdba8705fc642fd7815cbc11

) still shows the error happening, but I've only run an update --dump-sql and didn't init a new database or anything.

here's my mapping for one entity that causes this:

<?xml version="1.0" encoding="utf-8"?>
<doctrine-mapping>
	<entity name="BM2\SiteBundle\Entity\Building">
		<id name="id" type="integer">
			<generator strategy="IDENTITY"/>
		</id>
		<field name="workers" type="float"/>
		<field name="active" type="boolean"/>
		<field name="condition" type="integer"/>
		<field name="resupply" type="integer"/>
		<field name="current_speed" type="float"/>

		<many-to-one field="settlement" target-entity="Settlement" inversed-by="buildings"/>
		<many-to-one field="type" target-entity="BuildingType" inversed-by="buildings"/>

	</entity>
</doctrine-mapping>

and on " php app/console doctrine:schema:update --dump-sql" I get for this entity:

ALTER TABLE building ALTER current_speed SET ;

I do think it is related to the default column indeed, as adding this to an existing database required me to add it with a default value that is not reflected in the mapping data, so the current column definition for this entity is:

                                 Table "public.building"
    Column     |       Type       |                       Modifiers                       
---------------+------------------+-------------------------------------------------------
 id            | integer          | not null default nextval('building_id_seq'::regclass)
 settlement_id | integer          | 
 type_id       | integer          | 
 workers       | double precision | not null
 active        | boolean          | not null
 condition     | integer          | not null
 resupply      | integer          | not null
 current_speed | double precision | not null default 1.0

and if I drop the default (alter table building alter current_speed drop default) then the problem disappears. So at least there's a workaround now, thanks!

Comment by Steve Müller [ 30/Dec/13 ]

Tom Vogt The problem is composer installed from DBAL 2.3-dev branch. But the patch is currently only available in DBAL master. You have to test this with the current DBAL master somehow.

Comment by Tom Vogt [ 30/Dec/13 ]

confirmed fixed:

Updating dependencies (including require-dev)                          
  - Updating doctrine/dbal (2.3.x-dev 907f30d => dev-master 9ec63e2)
    Checking out 9ec63e25b572db79c09cacccb844e33ed435e479

  - Updating doctrine/orm (2.3.x-dev 1a30e0a => dev-master 58c57c5)
    Checking out 58c57c50bf3582a1672bc09733afab4167ebd5ba
php app/console doctrine:generate:entities BM2 --no-backup
...
ALTER TABLE settlement ALTER starvation DROP DEFAULT;
...

it is now correctly updating.

Thanks.

Comment by Steve Müller [ 30/Dec/13 ]

Benjamin Eberlei can you resolve please? I cannot do that...





[DBAL-4] missing column type "enum" Created: 27/Oct/09  Updated: 14/Jan/15  Resolved: 13/Apr/11

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

Type: New Feature Priority: Minor
Reporter: Christian Ehmig Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 2
Labels: None

Attachments: Text File enum_type_patch.patch    
Issue Links:
Dependency
depends on DBAL-1116 [GH-774] Added SET and ENUM types for... Resolved
Reference
is referenced by DBAL-89 MySqlPlatform does not handle enum a... Resolved
is referenced by DBAL-504 DBAL Enum fields migration issue / Po... Resolved
is referenced by DDC-2469 SQLite handling for ENUM-Fields Resolved

 Description   

The former supported column type "enum" is not defined in Doctrine\DBAL\Types\Type.

I've included a patch which enables the missing "enum" type in AnnotationDriver, SchemaTool and DBAL/Types. Currently, only the MySQL Platform is supported (others throw exceptions). Please have a look if you find this a possible solution. A new type "EnumType" has been added.

An example docblock syntax would be:

     /**
     * @Column(name="myenum", type="enum", values={"email","nickname"})
     */
    private $myenum;

patch attached.



 Comments   
Comment by Roman S. Borschel [ 27/Oct/09 ]

D2 has no enum type (because php has no enum type), we might need a new type class for this if necessary. Might be non-trivial.

Comment by Christian Ehmig [ 27/Oct/09 ]

Yes, a new type class is needed. It should be possible (like in D1) to configure the list of available enum elements.

example from D1 doc:

---
Test:
  columns:
    enumtest:
      type: enum
      values: [php, java, python]

Would be important regarding migration issues.

Comment by Christian Heinrich [ 13/Mar/10 ]

Roman, is your response to be considered a "we will work on this" or a "probably won't implement it". I'm asking because I was thinking whether I should get into this or not.

Comment by Benjamin Eberlei [ 14/Mar/10 ]

My take, given the flyweight architecture of our type-system this is only implementable with a specific Enum class in the userland. The only thing we could offer would be an abstract class to extend from. This would rather be a task for a Doctrine Extension in my opinion, or even a documentation/cookbook problem.

Comment by David Abdemoulaie [ 10/Apr/10 ]

I see this as a non-issue. It belongs in an extension. ENUM is specific to MySQL, and is one of the most misused columns.

Comment by Benjamin Eberlei [ 13/Jun/10 ]

Change to minor

Comment by Benjamin Eberlei [ 13/Apr/11 ]

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

That is everything we can provide.





[DBAL-89] MySqlPlatform does not handle enum and set data types Created: 10/Feb/11  Updated: 14/Jan/15  Resolved: 10/Feb/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: James Reed Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Attachments: File MySqlPlatform.php    
Issue Links:
Reference
relates to DBAL-4 missing column type "enum" Resolved
is referenced by DBAL-1116 [GH-774] Added SET and ENUM types for... Resolved

 Description   

If you do a reverse engineer of an existing database that includes enum and set columns the reverse engineer will fail. Ideally there could be a separate Doctrine type for these fields, but at a minimum it seems they should be treated as string values. I solved my reverse engineering problem by modifying the initializeDoctrineTypeMappings in the MySqlPlatform.php file (attached):

protected function initializeDoctrineTypeMappings()

{ $this->doctrineTypeMapping = array( 'tinyint' => 'boolean', 'smallint' => 'smallint', 'mediumint' => 'integer', 'int' => 'integer', 'integer' => 'integer', 'bigint' => 'bigint', 'tinytext' => 'text', 'mediumtext' => 'text', 'longtext' => 'text', 'text' => 'text', 'varchar' => 'string', 'string' => 'string', 'char' => 'string', 'date' => 'date', 'datetime' => 'datetime', 'timestamp' => 'datetime', 'time' => 'time', 'float' => 'float', 'double' => 'float', 'real' => 'float', 'decimal' => 'decimal', 'numeric' => 'decimal', 'year' => 'date', 'enum' => 'string', 'set' => 'string', ); }

 Comments   
Comment by Benjamin Eberlei [ 10/Feb/11 ]

There is a method on the platform "regsiterDoctrineMappingType" that modifies this array.

Enums and Sets cannot be generically supported by architectural choice.

Comment by James Reed [ 10/Feb/11 ]

Ah, didn't know about the regsiterDoctrineMappingType. Good solution. Thanks!

Comment by James Reed [ 10/Feb/11 ]

Actually, after searching the code the method is "registerDoctrineTypeMapping"





[DBAL-1116] [GH-774] Added SET and ENUM types for MySQL and fix issue with schema update tool Created: 14/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: ddl, enum, mysql, set, type

Issue Links:
Dependency
is required for DBAL-4 missing column type "enum" Resolved
Reference
relates to DBAL-89 MySqlPlatform does not handle enum a... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of dimak08:

Url: https://github.com/doctrine/dbal/pull/774

Message:

Set and Enum data types are one of the most popular. However, addition of these data types in the project creates a problem when updating of the database structure.



 Comments   
Comment by Doctrine Bot [ 14/Jan/15 ]

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

Comment by Doctrine Bot [ 14/Jan/15 ]

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

Comment by Marco Pivetta [ 14/Jan/15 ]

See http://stackoverflow.com/a/9057352/347063

ENUM and SET are non-portable types that will not be implemented by the DBAL due to the complexity behind their handling.





[DBAL-1108] [GH-769] Allow overriding implicit indexes Created: 08/Jan/15  Updated: 14/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: duplicate, explicit, fk, foreign-key, implicit, index, table

Issue Links:
Dependency
is required for DDC-2989 ORM should allow custom index names f... Resolved
Duplicate
is duplicated by DDC-3310 [GH-1138] Join column index names Resolved
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
relates to DBAL-1102 [GH-764] [DBAL-1063] Allow defining d... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/769

Message:

This is a follow-up patch for the change introduced in https://github.com/doctrine/dbal/pull/764.
It makes the `Table` class act more intelligent when it comes to preferring explicit over implicit indexes.
Currently it is necessary to construct a `Table` instance in a specific order to not have unnecessary duplicate indexes because of foreign keys. If you first add a foreign key and afterwards and explicit index that is fulfilling the implicit one, both indexes are stored. Instead it is more intelligent to replace the implicit by the explicit one if and only if the explicit one fulfills the implicit one.
This should also fix possible issues with how ORM's schema tool constructs a schema. See [here](https://travis-ci.org/doctrine/doctrine2/jobs/46321581#L307) where for a OneToOne relation on a primary key an additional regular index for the foreign key is created.



 Comments   
Comment by Doctrine Bot [ 09/Jan/15 ]

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

Comment by Doctrine Bot [ 09/Jan/15 ]

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





[DBAL-1114] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15

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

Type: Task Priority: Minor
Reporter: Marcin Zawadzki Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1093 [GH-757] Fix creating and dropping da... Resolved

 Description   

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database by command line with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
• PostgreSQL 9.2.4
• PHP 5.5.10

Any suggestions or workarounds for this issue?

Thank you



 Comments   
Comment by Steve Müller [ 13/Jan/15 ]

Issue introduced in DBAL-1093, to be fixed in DoctrineBundle. PR provided: https://github.com/doctrine/DoctrineBundle/pull/368





[DBAL-1093] [GH-757] Fix creating and dropping database on PostgreSQL Created: 26/Dec/14  Updated: 13/Jan/15  Resolved: 27/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create, database, drop, pgsql, postgresql

Issue Links:
Reference
is referenced by DBAL-1114 Problem with drop database on PostgreSQL Open

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/757

Message:

There is some useless code in the schema manager for PostgreSQL for creating and dropping a database. Moreover if either of those operations fails, the schema manager stays in an inconsistent state because the temporary connection that is set in the schema manager is not reverted back to the original connection.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by Doctrine Bot [ 27/Dec/14 ]

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





[DBAL-1113] [GH-772] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Cinal:

Url: https://github.com/doctrine/dbal/pull/772

Message:

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
��� PostgreSQL 9.2.4
��� PHP 5.5.10

Any suggestions or workarounds for this issue.

Thank you



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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





[DBAL-1062] upgrade from v2.4.3 to v2.5.0 is forcing recreating Indexes making Doctrine unusable Created: 05/Dec/14  Updated: 13/Jan/15  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1

Type: Bug Priority: Major
Reporter: gondo Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: index, rename
Environment:

any


Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1092 [GH-756] [DBAL-1062] Fix renaming ind... Resolved

 Description   

after executing 'composer update' i was upgraded to dbal v2.5.0
(im using "doctrine/orm": "~2.2,>=2.2.3" in composer.json)
im using Symfony 2.6.*

now when i try 'app/console doctrine:schema:update --dump-sql' i see that doctrine wants to recreate indexes on some tables for no practical reason
nothing changed in the code.

example:
DROP INDEX idx_a604da13a76ed395 ON table1;
CREATE INDEX IDX_B7E704F0A76ED395 ON table1 (user_id);
DROP INDEX uniq_b3319c7d77153098 ON table2;
CREATE UNIQUE INDEX UNIQ_C984F95777153098 ON table2 (code);

however when i try to execute this update, im getting this error:
General error: 1553 Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

this essentially prevents me from using automatic doctrine database mapping or using migration tools.



 Comments   
Comment by Marco Pivetta [ 05/Dec/14 ]

Downgraded to "Major", as this doesn't prevent usage of the DBAL at runtime.

You can still upgrade those indexes manually after having removed the FKs (to re-add them later on).

Seems like a case sensitivity issue of your setup: consider adding environment details.

Comment by Steve Müller [ 05/Dec/14 ]

Which database vendor are you using? Also interestingly the indexes get recreated with a different name. Thought of case sensitivity, too. I think the comparator nevertheless has to be adjusted to compare with identical case on index names.

Comment by gondo [ 05/Dec/14 ]

well it IS preventing me from using doctrine as it is.
i just downgraded dbal to v2.4.3 by adding "doctrine/dbal": "2.4.*", to my composer.js and everything is working fine. by that i mean, no commands to drop and create indexes.

im using mysql Ver 14.14 Distrib 5.6.21, for osx10.10 (x86_64) using EditLine wrapper

im developoing on OSX 10.10 and production is running CentOS.
i know that OSX is using case insensitive file system (i had to deal with it in the past when i was deploying to production)
but this time there is NO change in my code. zero. nothing.

if there was case sensitivity changes in dbal itself, that might be the problem, however that is nothing i can fix.

i would love to upgrade those indexes manualy, however i have no idea how to.
should i change something in the code? indexes were created and named by doctrine, not by me.
if you recommend updating database, that seems to be failing. i assume dropping indexes on live data might cause problems.
or is it safe to just drop and create these indexes in mysql cmd?

Comment by gondo [ 05/Dec/14 ]

i can not drop those indexes directly in mysql, im getting erros:
ERROR 1553 (HY000): Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

Comment by Steve Müller [ 05/Dec/14 ]

okay just checked, casing is not a problem as identifiers will be lowercased automatically in Doctrine\DBAL\Schema\Table for comparison.
Need further information about the underlying database being used...

Comment by Steve Müller [ 05/Dec/14 ]

gondo please for now don't try to solve the issue automatically because it looks like a real issue we need to figure out. Otherwise there will be little chance we get to know the real cause of the issue...

Comment by gondo [ 05/Dec/14 ]

@Steve Müller for now i've solved it by downgrading dbal to v2.4.*
do you need some more information from me?
unfortunately i can't give you all the code, company policy + its quite big. but i can dump you database schemas and entity declarations of affected tables if that will help. please let me know.

Comment by Steve Müller [ 05/Dec/14 ]

Hmm cannot reproduce the problem. What I did:

composer create-project symfony/framework-standard-edition path/

then added 'doctrine/dbal": "2.4.*"' to composer.json

composer install

then created entity with unique column name (to force auto index generation)

php app/console doctrine:database:create
php app/console doctrine:schema:create

then changed 'doctrine/dbal": "2.4."' to 'doctrine/dbal": "2.5."' in composer.json

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

Tried that with pdo_mysql on ubuntu 14.04 x86_64.

Comment by gondo [ 05/Dec/14 ]

were you creating some tables with foreign keys?

Comment by gondo [ 05/Dec/14 ]

here is the list of all indexes what tries to be recreated:
http://pastebin.com/nFYp6pnp

here are the definitions of some entities + their schemas and indexes from mysql:
notification_channel
http://pastebin.com/EfkcyUnf
http://pastebin.com/Ngd1Lkbe

online_payment_option
http://pastebin.com/R5waCF35
http://pastebin.com/ti4TzyKX

user_settings
http://pastebin.com/gxed5kjY
http://pastebin.com/EiCBWKNQ

i've also tried to specify index with custom name as per http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index
to prevent this index recreation but without no luck, it was ignored.
i've tried to change the definition of `online_payment_option` table like this:
@ORM\Table(name="online_payment_option", options=

{"collate"="utf8_unicode_ci", "charset"="utf8"}

, indexes={@ORM\Index(name="TEST", columns=

{"code"}

)})
but after trying schema:update im still getting the same output http://pastebin.com/nFYp6pnp

Comment by Steve Müller [ 12/Dec/14 ]

Okay I think I get the problem now. I don't get any suggested update statements when upgrading from a DBAL 2.4 created schema to DBAL 2.5.
I assume this is because even in DBAL 2.4 the indexes are created with the name your update command suggests. For example:

DROP INDEX idx_a604da13a76ed395 ON notification_channel;
CREATE INDEX IDX_B7E704F0A76ED395 ON notification_channel (user_id);

You have an index named idx_a604da13a76ed395 in your database, the index name DBAL generates is IDX_B7E704F0A76ED395. Even in 2.4 this is the name that is generated by DBAL. The reason why you get those update statements is because index names are compared since DBAL 2.5 as part of the new index renaming feature.
I guess that the index name generation has changed in an earlier version of DBAL (can't prove that right now). So you probably created the index with a much earlier DBAL version back then and now it wants to rename it. This should be a one time "upgrade" step.
The reason why manually defining an index in your entity with a custom name has no effect is because ORM's schema tool prefers auto generated indexes over custom indexes if both fullfill the same criteria. This is something to be fixed in ORM then.
The foreign key problem is indeed something we have to deal with in DBAL. The update schema command should create SQL to first drop FKs, then rename indexes and afterwards recreate FKs again.
Hope that helps for now. Sorry for the upgrade circumstances...

Comment by gondo [ 12/Dec/14 ]

thank you very much for looking into this and spending time on it!
it is very likely that those indexes were created in older version, however I'm 100% that it is not older than 1 year.

if i understand correctly, there are several things what needs to be fixed (manual overwriting of indexes and generating proper update schema command)

is this something what will be fixed? or does this fall into "edge case" bucket and will be left until more people experience same problem?
so far I'm fine staying on 2.4.3 but eventually i would like to upgrade. if the fix is planned, i can wait. if not, than i can create manual update now.

thanks one more time

Comment by Steve Müller [ 12/Dec/14 ]

I am already on that foreign key issue. As soon as that is fixed, the generated update SQL should be valid so that it can safely be run and you don't need to update your index names manually then. As what the manual index preference is concerned that needs to be fixed in ORM. I might also have a look into this issue afterwards. I think it won't take long until DBAL 2.5.1 as there is another critical issue that needs to be adressed sonner than later.
With 2.5.1 you should be safe to update your schema automatically.

Comment by gondo [ 12/Dec/14 ]

perfect!
thats much sooner than i expected
thanks again

Comment by Gábor Tóth [ 22/Dec/14 ]

This is a deal breaker for us. We cannot use 2.5 branch until it is not fixed.

Comment by Marco Pivetta [ 22/Dec/14 ]

Gábor Tóth you are not forced to upgrade for now: consider sending a patch if it is that critical to you.

Comment by Steve Müller [ 24/Dec/14 ]

Gábor Tóth I provide a patch here: https://github.com/doctrine/dbal/pull/756

Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by gondo [ 13/Jan/15 ]

i've just updated to 2.5.1 and the problem remains

Comment by Steve Müller [ 13/Jan/15 ]

gondo can you please post the SQL created by the schema tool and the error you get? Thanks.

Comment by gondo [ 13/Jan/15 ]

same as on the beginning, basically nothing changed for me :/
http://pastebin.com/NqP9aEae

Comment by Steve Müller [ 13/Jan/15 ]

Do you get an error when executing the SQL? I can see that foreign keys are now dropped before dropping and recreating the index which is part of the patch. The reason why the schema manager is still outputting upgrade SQL was discussed here before (index name mismatch). However this should only happen once now and it should work without an error.

Comment by gondo [ 13/Jan/15 ]

ah i see.
i was expecting that there will be no SQL update needed after this patch, but now i understand what you mean.
i was only doing `app/console doctrine:schema:update --dump-sql`
after trying `app/console doctrine:schema:update --force` (on localhost only) everything seems to be fine

perfect! i will do some more testing, hopefully i ll not destroy production database with this

Comment by Steve Müller [ 13/Jan/15 ]

Unfortunately we cannot prevent SQL generation for users that have different index names in their database than those created by the mapping. Those users will have to "resync" index names once and should be fine afterwards. If we would not compare index names, the index renaming feature would not be possible.
You should be safe to run the SQL in production as it is just dropping and recreating indexes / foreign keys.





[DBAL-1061] [GH-737] [DBAL-1058] [2.4] Fix database names introspection for SQL Server Created: 05/Dec/14  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4
Fix Version/s: 2.4.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Resolved
relates to DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/737

Message:

Backport of #736 to 2.4 branch.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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





[DBAL-1060] [GH-736] [DBAL-1058] Fix database and namespace introspection for SQL Server Created: 05/Dec/14  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Resolved
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/736

Message:

It looks like some SQL Server versions / setups need system tables to be queried lowercased otherwise causing errors.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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





[DBAL-1107] Doctrine Migrations diff gets different table name for up and down Created: 06/Jan/15  Updated: 12/Jan/15

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

Type: Bug Priority: Minor
Reporter: Krzysztof Hasiński Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've changed one field in my model from not null to default null, generated a migration using diff and got:

class Version20150105175136 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE badge ALTER company_id DROP NOT NULL');
    }

    public function down(Schema $schema)
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE Badge ALTER company_id SET NOT NULL');
    }
}

Please note the name Badge and badge in up and down migrations. Is this a bug?

I've got response from Doctrine Migrations project:

"This should be reported in the issue tracker of the DBAL project, because the Migrations project is not responsible for computing the schema changes."

Link to this issue on github: https://github.com/doctrine/migrations/issues/197



 Comments   
Comment by Steve Müller [ 07/Jan/15 ]

Can you please provide the ORM mapping information before and after the migrations:diff command?
Did you maybe remove or add explicit quotes from/to your table name mapping? Really hard to evaluate without further information...

Comment by Krzysztof Hasiński [ 07/Jan/15 ]

Sure thing:

Entity (imports + header):

use Doctrine\ORM\Mapping as ORM;
use JsonSerializable;
use Iphp\FileStoreBundle\Mapping\Annotation as FileStore;
use Symfony\Component\Validator\Constraints as Assert;
/**
 * Badge
 * @FileStore\Uploadable
 * @ORM\Table()
 * @ORM\Entity
 */
class Badge implements JsonSerializable

Field before change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=false)
     */
    private $company;

Field after change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=true)
     */
    private $company;

Comment by Steve Müller [ 09/Jan/15 ]

How is your table named in the database? Is it "Badge" or "badge"? I assume that your table was created with the name "Badge" (with a capital letter). If this is the case, did you have your table name explicitly quoted in the mapping some time before like `Badge` or "Badge" (including backticks/quotes)?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Created using migrations:diff, relevant line (note the capital letter):

        $this->addSql("CREATE TABLE Badge (id INT NOT NULL, user_id INT DEFAULT NULL, team_id VARCHAR(63) NOT NULL, name VARCHAR(255) NOT NULL, image VARCHAR(512) NOT NULL, condition TEXT NOT NULL, PRIMARY KEY(id))");

In all subsequent migrations any ALTER TABLE (generated) is using this mixed case for up and down.

Status in db now (from psql):

khasinski=> \d badge
                          Table "public.badge"
   Column    |          Type           |            Modifiers            
-------------+-------------------------+---------------------------------
 id          | integer                 | not null
 user_id     | integer                 | 
 company_id  | character varying(63)   | not null
 name        | character varying(255)  | not null
 image       | text                    | not null
 condition   | text                    | 
 description | character varying(1024) | default NULL::character varying
Indexes:
    "badge_pkey" PRIMARY KEY, btree (id)
    "idx_3f316719296cd8ae" btree (company_id)
    "idx_3f316719a76ed395" btree (user_id)
Foreign-key constraints:
    "fk_3f316719296cd8ae" FOREIGN KEY (company_id) REFERENCES company(id)
    "fk_3f316719a76ed395" FOREIGN KEY (user_id) REFERENCES guser(id)
Referenced by:
    TABLE "userbadge" CONSTRAINT "fk_9a64d968f7a2c2fc" FOREIGN KEY (badge_id) REFERENCES badge(id)
Comment by Marco Pivetta [ 09/Jan/15 ]

Can you please tell us the exact versions (see composer.lock) of the DBAL, ORM and migrations installed?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Sure, always happy to help

DBAL:

            "name": "doctrine/dbal",
            "version": "v2.5.0",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/dbal.git",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/dbal/zipball/71140662c0a954602e81271667b6e03d9f53ea34",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34",
                "shasum": ""
            },

ORM:

            "name": "doctrine/orm",
            "version": "v2.4.7",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/doctrine2.git",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/doctrine2/zipball/2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "shasum": ""
            },

Migrations:

            "name": "doctrine/doctrine-migrations-bundle",
            "version": "dev-master",
            "target-dir": "Doctrine/Bundle/MigrationsBundle",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/DoctrineMigrationsBundle.git",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/DoctrineMigrationsBundle/zipball/81575a4316951125ce408c70f30547c77d98f78a",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a",
                "shasum": ""
            },
Comment by Steve Müller [ 09/Jan/15 ]

I think I get the problem here. Btw do the migrations actually fail? IMO this is not really an "issue" as casing of identifiers is ignored by PostgreSQL unless you explicitly quote identifiers. So:

ALTER TABLE badge ALTER company_id DROP NOT NULL;
ALTER TABLE Badge ALTER company_id DROP NOT NULL;
ALTER TABLE BADGE ALTER company_id DROP NOT NULL;

all do the same thing because PostgreSQL internally lowercases identifiers if they are not quoted.
Please see: http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.VLAQal0z1C0

Comment by Steve Müller [ 09/Jan/15 ]

BTW if you find it annoying that migrations uses "Badge" instead of "badge" you'll just have to use another naming strategy.
See: http://doctrine-orm.readthedocs.org/en/latest/reference/namingstrategy.html

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

I am well aware, that PostgreSQL use lowercase when it comes to table names without a quote, that's why I'm not considering a major bug, just some inconsistency, that I was curious about. It seems like up and down migrations should read the data from a single source of truth.

I might be mistaken, but it seems like migrations are important enough to care about this kind of minor details.

Comment by Steve Müller [ 12/Jan/15 ]

The DBAL schema manager that introspects your database does not know about your schema mappings you defned in ORM so it won't know that you created the table with an uppercase first letter. If you want consistency, please use another naming strategy in ORM or quote your table identifier explicitly in your mapping.
Doctrine will only quote reserved keyword identifiers and does not quote all identifiers automatically. There have been several discussions about this to why auto-quoting brings more problems than it solves.

Comment by Krzysztof Hasiński [ 12/Jan/15 ]

As I said - I am aware of that and it's probably ok

So my understanding is that it creates "up" migrations from ORM (which knows about the capital letter) and "down" using DBAL schema manager, is that correct?

Comment by Steve Müller [ 12/Jan/15 ]

I think you mean the other way around. See here: https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Tools/Console/Command/DiffCommand.php#L101-L102
For "up" migrations the ORM schema mapping is compared against the database schema mapping (base). For "down" migrations it's the other way around.





[DBAL-1109] unique-constraints names not quoted on create Created: 11/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Minor
Reporter: Anders Jenbo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: create, index, quoted, table
Environment:

Ubuntu 14.04, MySQL 5.5, MySQLi driver

Actual version is 2.4.7 but it doesn’t appear on the list.



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because unique is a key word.
<unique-constraint name="unique" columns="unique"/>

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'un
ique (`unique`), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unic' at line 1






[DBAL-1112] sqlite - Insert statement with keyword as column name raises sql-error Created: 12/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

Type: Bug Priority: Major
Reporter: Florian Semm Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

We are using a sqlite db in our unit tests. During fixtures-load a error occurs:

[Doctrine\DBAL\Exception\SyntaxErrorException]
An exception occurred while executing 'INSERT INTO state (name, type, group) VALUES (?, ?, ?)':
SQLSTATE[HY000]: General error: 1 near "group": syntax error

We are using for all queries, in our symfony2 application, the doctrine-orm (v2.4.7). So this query is auto-generated.

The reason for this error is a wrong syntax of the insert statement:

INSERT INTO state (name, type, group) VALUES ('a_name', 'a_type', 'a_group');

The group column is a sqlite-keyword and must surround with " or '. A query like this

INSERT INTO state (name, type, 'group') VALUES ('a_name', 'a_type', 'a_group');

works fine.



 Comments   
Comment by Florian Semm [ 12/Jan/15 ]

I found the resolution in the documentation





[DBAL-1111] [GH-771] Fix unique index exception handling for an index on multiple columns in PHP 5.4 Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, mysql, php-5.4, unique


 Description   

This issue is created automatically through a Github pull request on behalf of rbayliss:

Url: https://github.com/doctrine/dbal/pull/771

Message:

In SQLite under PHP 5.4, when I violate a unique index on multiple columns by creating a duplicate record, the PDO Exception thrown is "SQLSTATE[23000]: Integrity constraint violation: 19 columns X, Y are not unique". This PDO exception message is not parsed by the AbstractSQLiteDriver and converted to a UniqueConstraintViolationException as expected, and as happens in PHP 5.5, so only a generic DriverException is thrown, making error handling much harder.

This pull request adds "are not unique" as a string that is checked for in the exception handling code.



 Comments   
Comment by Doctrine Bot [ 11/Jan/15 ]

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

Comment by Doctrine Bot [ 11/Jan/15 ]

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





[DBAL-1110] [GH-770] Moved Doctrine\Tests namespace to composer autoload-dev. Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

Status: Closed
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: autoloader, composer, phpunit, tests


 Description   

This issue is created automatically through a Github pull request on behalf of guilhermeblanco:

Url: https://github.com/doctrine/dbal/pull/770

Message:



 Comments   
Comment by Doctrine Bot [ 11/Jan/15 ]

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

Comment by Doctrine Bot [ 11/Jan/15 ]

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





[DBAL-1063] Exceptions from SchemaTool when running with DBAL 2.5.0 Created: 06/Dec/14  Updated: 09/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: flack Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, foreign-keys, index, schemadiff

Issue Links:
Reference
relates to DBAL-50 PgSQL driver does not create indexes ... Resolved
relates to DBAL-1062 upgrade from v2.4.3 to v2.5.0 is forc... Resolved
relates to DBAL-1074 [GH-743] Add failing unit test relate... Resolved
is referenced by DBAL-1102 [GH-764] [DBAL-1063] Allow defining d... Resolved
is referenced by DDC-3478 [GH-1239] Fix index duplication for u... Resolved
is referenced by DBAL-1108 [GH-769] Allow overriding implicit in... Resolved

 Description   

I'm not entirely sure it it is related to DBAL-1062, but I'm seeing some similar problems since updating to 2.5.0. The problem I'm having occurs only once per table, and only for some tables, so it is kind of hard to debug. What I've found out so far is that it happens when I manually define an index on a column which I name f.x. 'colname_idx', and then later Doctrine wants to add an index to the column automatically (e.g. when it is an association field), in which case it generates an index name like 'IDX_CF2713FD16F4F95B'.

An index with this name already exists (from the last run of the SchemaTool, presumably). The isFullfilledBy function in Doctrine\DBAL\Platforms\AbstractPlatform\Index detects that the both the manually-named index and the automatically-named one are identical and thus ignores them in Doctrine\DBAL\Schema\Table::_addIndex.

When the schema read from the database is compared to the one generated from metadata in Doctrine\DBAL\Schema\Comparator::diffTable, $table1 will list 'colname_idx' and the one from $table2 will say 'IDX_CF2713FD16F4F95B'. So it will be counted as a rename, and the rename SQL (for mysql at least) is

DROP INDEX colname_idx ON tablename
CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)

But as mentioned before, IDX_CF2713FD16F4F95B already exists, so I get

  [Doctrine\DBAL\Exception\DriverException]                                                          
  An exception occurred while executing 'CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)':          
  SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'IDX_CF2713FD16F4F95B'

Since the DROP statement before was executed successfully, on the next SchemaTool run, the existing index will be detected correctly for $table1, and thus no rename is issued.



 Comments   
Comment by Steve Müller [ 08/Dec/14 ]

From a first glance this issue is caused by ORM's schema tool which is creating indexes implicitly for unique columns and associations. Seems it doesn't play well with the new index renaming feature from DBAL 2.5 if you also define indexes explicitly that also fullfill those auto generated ones.
Maybe we have to asjust the schema tool to make a certain preference of explicitly defined indexes over auto generated ones if both fullfill the same criteria.

Comment by flack [ 08/Dec/14 ]

Well, making the schema tool smarter is certainly a good idea, since in 2.4 it created duplicate indexes (different name, same function) if I understood your theory correctly.

But there are some things on the DBAL side that I wonder about, e.g. shouldn't dbal do a sanity check before renaming? Or is there one that doesn't trigger because it cannot detect that an index with the target name already exists?

As far as I understood it, the schema read from the database was missing the one index (auto-generated one by SchemaTool), because Doctrine\DBAL\Schema\Table::_addIndex refused to add it on the grounds that it isFullfilledBy the manually-created index. This sounds like a very valid optimization for the case where I plan to write a schema to the database, but it is not at all helpful when creating a representation of an existing database. So I wonder if this case shouldn't be handled differently.

The other thing I'm still unclear about is why the second schema (the one coming from the driver) has the autogenerated index instead of the manual one. I suppose it could be a timing issue, but if the driver and the schematool both were to call _addIndex in the same order, the issue wouldn't even occur. Which might make it difficult to write a unit test for it

Comment by Steve Müller [ 09/Dec/14 ]

flack I did not test anything about this issue yet. It's all just speculation at the moment. What we'll have to do is try reproducing it in a test case. I would propose adding a test case to ORM first as this is your main entry point. Would be awesome if you could PR such a test case that reveals the issue then we can make further inspections. Still not sure whether it's a DBAL or ORM issue or maybe even both...

Comment by flack [ 15/Dec/14 ]

I've added two tests now:

https://github.com/doctrine/dbal/pull/743

The first one shows a discrepancy between Table::getIndexes and SchemaManager::listTableIndexes (which might be the root cause of the problem), and the second one reproduces the exception mentioned above.

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request

Comment by Doctrine Bot [ 24/Dec/14 ]

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

Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by Marco Pivetta [ 03/Jan/15 ]

Suggestion: what if we rename indexes only when there is one and exactly one index in the diff before and after? Seems like there is a rename going on in any case right now.

Comment by Marco Pivetta [ 03/Jan/15 ]

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request

I've linked the issues together

Comment by flack [ 03/Jan/15 ]

@Marco: The problem with your suggestion is that the diff always only contains one index because of a (IMHO misguided) optimization in Doctrine\DBAL\Schema\Table::_addIndex. This test case shows the problem:

https://github.com/flack/dbal/commit/6ee814939525e15e136c9527c86967fba89860a3#diff-921db63349be598a376afb1584ccc8b5R113

Two indexes are read from the database, but only the first one is added to the Doctrine\DBAL\Schema\Table object, because the second one is discarded because of the isFulfilledBy check. So for the SchemaTool, it always looks like there is one index in DB and one in schema. If both are read in the same order ([index1, index2] from db and schema), then you have no problem. But if they are read in different oder ([index1, index2] from db and [index2, index1] from schema or the other way around), then the Exception hits.

Comment by Marco Pivetta [ 03/Jan/15 ]

The problem is indeed https://github.com/doctrine/dbal/blob/89d4f06fb4ff6e7b8f3c29a7307bf66203e09922/lib/Doctrine/DBAL/Schema/Table.php#L492-L497, which was introduced because of reasons explained in https://github.com/doctrine/dbal/blob/89d4f06fb4ff6e7b8f3c29a7307bf66203e09922/lib/Doctrine/DBAL/Schema/Table.php#L541-L543.

That logic should be manually triggered instead of implicitly executed every time.

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-50] PgSQL driver does not create indexes on foreign key columns Created: 18/Aug/10  Updated: 09/Jan/15  Resolved: 11/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Critical
Reporter: Petr Motejlek Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DDC-3478 [GH-1239] Fix index duplication for u... Resolved

 Description   

The PostgreSQL database does not create indexes for foreign key columns, the user has to create them by hand. I think that indexes for foreign keys should be created automatically... On my system, an index will not be created automatically for the group_id column in the user table.

/**
 * @Entity
 */
class User {
    /**
     * @ManyToOne(targetEntity="Group", inversedBy="users")
     */
    protected $group;
}

/**
 * @Entity
 */
class Group {
    /**
     * @OneToMany(targetEntity="User", mappedBy="group")
     */
    protected $users;

    public function __construct() {
        $this->users = new \Doctrine\Common\Collections\ArrayCollection();
    }
}

I am using current git clone and PgSQL 8.4.



 Comments   
Comment by Petr Motejlek [ 09/Sep/10 ]

I'd just like to add that there's an even worse problem with this – the indices are not created even for tables that Doctrine creates automatically – for example the joining tables...

Comment by Benjamin Eberlei [ 09/Sep/10 ]

i'll look into it.

Comment by Benjamin Eberlei [ 11/Sep/10 ]

Fixed in master, leading to several follow up bugs that all had to be fixed:

1. generate identifier allowed first char to be a number
2. postgresql composite foreign key detection left a space in the second (and more) column names
3. Index column names were not sanitized to lower-case, leading to comparison bugs.

There has been a major refactoring now such that, for each foreign key there is always an explicit index being created. On SQLite, Postgres and Oracle this can lead to quite some additional indexes being created now using SchemaTool --update. MySQL already did this implicitly.

There are now heuristics that detect duplicate indexes (based on columns indexed) and override rules (adding primary on columns foo, bar will delete index on columns foo bar).

Comment by Benjamin Eberlei [ 11/Sep/10 ]

Note, this commit will not get into Doctrine ORM master unless you update the git-submodule explicitly:

cd lib/vendor/doctrine-dbal
git checkout master

For RC-1 this will be visible to the ORM trunk/master also.





[DBAL-1102] [GH-764] [DBAL-1063] Allow defining duplicate indexes on a table Created: 03/Jan/15  Updated: 08/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, index, rename, schema

Issue Links:
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1108 [GH-769] Allow overriding implicit in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/764

Message:

This PR removes silent dropping of "duplicate" indexes on a table if two indexes fulfill each other or one overrules the other.
This is necessary to make detection of renamed indexes work properly (introduced in 2.5). Currently there are situations where false positive index renamings are detected because of race conditions.

*Example*

An ORM entity contains an association which adds a foreign key constraint to the underlying table. Foreign key constraints always create implicit indexes on the particular columns.
The entity also contains a mapping for a custom named index fulfilling the foreign key column(s).
The ORM schema tool first adds the foreign key constraint to the table, implicitly creating an index. Afterwards it adds the custom named index which is dropped silently by the table instance because it is considered a "duplicate".
So the table instance created by the schema now contains the auto generated index but not the custom named one.
When using the schema tool to update the schema, the DBAL schema manager is utilized to create the "online" schema. The schema manager detects two indexes in the database, the auto generated one and the custom named one (manually created by the user).
When the schema manger creates the table instance it eventually adds the custom named index first which results in the auto generated index being dropped silently.
When comparing both "offline" and "online" schema, the comparator detects an index rename which actually is none.
This leads to failing `DROP INDEX` and `CREATE INDEX` SQL.

Besides this issue "duplicate" indexes are totally legit and DBAL should not decide whether or not to create an index. This should be user responsibility.

This implementation is much more transparent and less error prone and opens up more flexibility for the user to define indexes on tables.

/cc @flack @Ocramius @beberlei



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-321] [GH-184] Added INSERT support to dbal QueryBuilder Created: 13/Aug/12  Updated: 08/Jan/15  Resolved: 08/Jan/15

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: insert, querybuilder, sql

Issue Links:
Reference
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
relates to DBAL-673 [GH-420] [DBAL-320] Add insert operat... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of Tim-Erwin:

Url: https://github.com/doctrine/dbal/pull/184

Message:

See also http://www.doctrine-project.org/jira/browse/DBAL-320
Please review and commit as fits.



 Comments   
Comment by Doctrine Bot [ 20/Dec/13 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-320] allow SQL QueryBuilder to do INSERTS Created: 13/Aug/12  Updated: 08/Jan/15  Resolved: 23/Dec/13

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

Type: New Feature Priority: Major
Reporter: Tim Mundt Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File INSERT-for-doctrine-SQL-QueryBuilder.patch    
Issue Links:
Reference
relates to DBAL-636 QueryBuilder insert Resolved
is referenced by DBAL-182 Insert and Merge Query Objects Open
is referenced by DBAL-321 [GH-184] Added INSERT support to dbal... Resolved
is referenced by DBAL-599 Add support of insert and insert sele... Open

 Description   

With

$db = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
$qb = $db->createQueryBuilder();

this QueryBuilder I'm able to do SELECT, UPDATE and DELETE. However, INSERT is not possible. Are there any good reasons for this?

Attached you find a patch that until now works fine for me. I don't know, however, if there are any side effects.



 Comments   
Comment by Marco Pivetta [ 13/Aug/12 ]

Insert is not supported by DQL

Comment by Tim Mundt [ 13/Aug/12 ]

Well, that was quick and not helpful. I have read about the QueryBuilder in the ORM package. For some reason with persistence (that other libraries don't have), insert cannot be supported. However, I'm talking about DBAL here. What good reason is there not to support INSERT??

Comment by Tim Mundt [ 13/Aug/12 ]

see previous comment, I'd appreciate some clarification

Comment by Marco Pivetta [ 13/Aug/12 ]

Tim Mundt Ouch, no, it was my fault, sorry.
I confused the project related to the issue.

Comment by Marco Pivetta [ 13/Aug/12 ]

This is actually valid (even the patch, though it needs to adds tests)

Comment by Tim Mundt [ 13/Aug/12 ]

Glad to hear there seems to be no fundamental problem with this. Can I somehow help this patch go into the code? I'm not familiar with the tests here. If you give me some pointer, maybe I can come up with something useful. On the other hand, it could be a good idea for some more involved people to have a look at this before.

Comment by Marco Pivetta [ 13/Aug/12 ]

You'd need to add tests in https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/Query/QueryBuilderTest.php (to be included in your patch or in a github pull request)
A Github PR is also the fastest way to get your code reviewed since not everyone visits the issue tracker.

Comment by Tim Mundt [ 13/Aug/12 ]

Here's the PR: https://github.com/doctrine/dbal/pull/184

Comment by Doctrine Bot [ 20/Dec/13 ]

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

Comment by Steve Müller [ 23/Dec/13 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/7502dae2e0d8e01e2f6f08cb5323ed754e72bac4





[DBAL-673] [GH-420] [DBAL-320] Add insert operation to QueryBuilder Created: 19/Nov/13  Updated: 08/Jan/15  Resolved: 20/Dec/13

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-321 [GH-184] Added INSERT support to dbal... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/420

Message:

This adds the possibility to execute insert statement with `QueryBuilder`. This is another approach to the existing PR #184.
Currently only single inserts are supported, as multi-insert-statements are more complicated and maybe not applicable for standard `QueryBuilder`.



 Comments   
Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-218] Add Object for BulkInsert Abstraction Created: 05/Feb/12  Updated: 08/Jan/15

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

Type: Task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
relates to DBAL-994 [GH-682] [WIP] [DBAL-218] Add bulk in... Open




[DBAL-994] [GH-682] [WIP] [DBAL-218] Add bulk insert query Created: 30/Sep/14  Updated: 08/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-218 Add Object for BulkInsert Abstraction Open

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/682

Message:

This is an approach to make use of database vendors' bulk row insert query syntax.
As the nature of bulk inserts usually is to insert a LOT of rows into a table (primarily from an external source), the implementation tries to focus on good performance and low memory consumption. It is NOT intended for `INSERT INTO ... SELECT ...` statement queries.

TODO:

  • Add an "executor" class that encapsulates the `BulkInsertQuery` object, adds options like bulk size and internally automatically evaluates the underlying platform's limits for a single `INSERT` statement and splits queries accordingly.
  • Evaluate platforms' max insert rows per `INSERT` statement and implement in platforms.
  • Add unit tests for quoted identifiers.
  • Add functional tests.

Future additions:

  • Add support for expressions.
  • Query builder (if there will be more bulk insert queries like `INSERT INTO ... SELECT ...`)?

Open for discussion. Ideas welcome!






[DBAL-1096] schema-tool:update does not understand columnDefinition correctly Created: 30/Dec/14  Updated: 08/Jan/15  Resolved: 31/Dec/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Morel Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-167 Schema comparator doesn't work proper... Open
Reference
relates to DDC-1657 The Doctrine cli tool does not handl... Resolved
relates to DDC-625 orm:schema-tool:update --dump-sql sho... Resolved

 Description   

This issue is similar to the old DDC-625 and to DDC-1657, but its scope is limited to columns declared with columnDefinition.

Take this entity:

class Faq
{
    /**
     * @ORM\Column(type="integer", columnDefinition="TINYINT(3) UNSIGNED NOT NULL")
     *
     * @var integer
     */
    private $position;
}

The command doctrine orm:schema-tool:update --dump-sql generates the following output:

ALTER TABLE Faq CHANGE position position TINYINT(3) UNSIGNED NOT NULL;

Even though the column is already declared this way. If I manually execute this query, and run the tool again, I get the same output.

I'm using Doctrine 2.4.7 with PHP 5.5.12 and MySQL 5.6.17.



 Comments   
Comment by Marco Pivetta [ 31/Dec/14 ]

The schema tool can't and won't handle diffs containing custom columnDefinition.

Comment by Benjamin Morel [ 31/Dec/14 ]

@ocramius Can you tell me why? Can't it at the very least compare them as strings, to avoid repeating endlessly the same queries?

Comment by Marco Pivetta [ 31/Dec/14 ]

That's exactly the problem: string comparison won't work in these cases, because of minor mismatches and because the column definition may include special markers, comments, definitions and so on in scrambled order.

This limitation is also documented in http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html#column

Handling it goes beyond the scope of the schema comparator, as the complexity to deal with it is not worth the effort.

Comment by Benjamin Morel [ 31/Dec/14 ]

While I fully understand these concerns, it's really disappointing to have to either stick to default, unoptimized data types such as INT when you only need a 8- or 16-bit integer, or to have to give up the command-line schema validation tool that will always go red.

The same issue applies when using custom data types such as Geometry or LocalDate, even when using supported SQL declarations.
This restricts a lot what you can do with the ORM while keeping the convenience of the schema tools!

I may have a few ideas to try out to make this work; if the core team is not 100% opposed to the concept, I could open a PR with a proof of concept at some point.

Comment by Marco Pivetta [ 31/Dec/14 ]

Fine tuning is the job of a DBA, not of the schema-tool. The schema-tool is by far a silver bullet.

Comment by Steve Müller [ 31/Dec/14 ]

Benjamin Morel if you find a way to make custom columnDefinitions comparable in a reasonable way, go ahead, make a contribution. It's not that we are totally against it, we just didn't find a good solution so far to make it work in a usable way. By the way, this is actually a DBAL issue, moving.

Comment by Christophe Coevoet [ 31/Dec/14 ]

Note that for custom data types, the SchemaTool supports comparing them if you use custom DBAL types to map them instead of using an existing type and adding a customDefinition property in it (the result might even be a better integration)

Comment by Benjamin Morel [ 31/Dec/14 ]

@Christophe Hmm I'm going to play a bit with this, but the LocalDate custom type I mentioned above, even though it uses $platform->getDateTypeDeclarationSQL(), is not properly handled by the SchemaTool either (it also endlessly suggests the same DDL)!

Comment by Steve Müller [ 31/Dec/14 ]

Benjamin Morel try making your custom type a commented type. This should make the schema manager be able to distinguish your custom type from the default DateType.
Override the method requiresSQLCommentHint() in your custom type class and let it return true.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller It works indeed with requiresSQLCommentHint(), I didn't know about that, thank you.

As far as I can see, the commented types are not checked by the SchemaTool: if I manually change a commented column type in the database, schema-tool:update won't offer me to fix it.

Could we do the same thing for columns with a columnDefinition? i.e. comment them with DC2Type:integer or DC2Type:string or whatever the native type is, and have the SchemaTool skip them?

Comment by Steve Müller [ 05/Jan/15 ]

Benjamin Morel actually it is the DBAL schema manager that is extracting the custom type name from the column's comment and then mapping it accordingly.
For instance if your custom type is called "money" (which is based on the native "decimal" type for example), DBAL will add the string "(DC2Type:money)" to the column's comment on creation/update. On reverse engineering the column from the database the schema manager will first detect the column as "decimal" (native type), then check for the custom type string in the comment and convert it into the "money" type.
This should work out of the box but is processed by DBAL, not ORM's schema tool. The schema tool just utilizes DBAL's schema manager here.
Speaking of custom columnDefinition your idea sounds reasonable to me and I think to remember that something similar has been proposed in the past. However to make matching and extraction easier we should hash the columnDefinition string somehow.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller Including a hash of the column definition in the DC2Type comment is a good idea, however it would only detect when you update the definition in the entity, not when you update the column type in the database manually.

I would be happy to work on this suggestion anyway, but I'm not sure where to start as I'm not comfortable with the internals of the schema manager.

Comment by Steve Müller [ 05/Jan/15 ]

Benjamin Morel of course we would have to make a compromise here. Comparing the column declaration SQL coming from the database with an arbitrary column declaration string from the mapping is not safe and also impossible considering that you usually use the columnDefinition to define vendor specific semantics for the column that DBAL does not/cannot support.
Implementing this feature would be similar to the commented type one.

Places to start:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L1085-L1112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L129-L132 (needs to be adopted for all schema managers)
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L497-L525

Those should be the important parts to adopt. Feel free to provide a PR

Comment by Steve Müller [ 08/Jan/15 ]

Related: DBAL-167





[DBAL-167] Schema comparator doesn't work properly with columnDefinition's Created: 17/Sep/11  Updated: 08/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Platforms, Schema Managers
Affects Version/s: 2.0.8, 2.1, 2.1.1, 2.1.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Dmitry Strygin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-1096 schema-tool:update does not understan... Resolved

 Description   

Schema comparator will mostly always return changed properties on columns for entities defined with columnDefinition even they are identical in the DB. This is due to weak low-lever compatibility of SchemaTool#getCreateSchemaSql() and SchemaTool#getSchemaFromMetadata() – the first one doesn't reconstruct columnDefinition, and the other one never supports 'fixed', 'default', cannot determine, whether it is boolean or integer (ex. TINYINT in the DB), etc...

All this results in extremely annoying unnecessary alter-table-change-columns surrounded by dropping and after that re-enabling constrains dependent on those columns.

I mean stuff like this:

symfony2#app/console doctrine:schema:update --dump-sql
...
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3F92F3E70;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A37A3ABE5D;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3EE551564;
ALTER TABLE es_hotels CHANGE is_active is_active TINYINT(1) NOT NULL DEFAULT '1', CHANGE checksum checksum CHAR(32) DEFAULT NULL;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3F92F3E70 FOREIGN KEY (operator_id, country_id) REFERENCES es_countries(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A37A3ABE5D FOREIGN KEY (operator_id, resort_id) REFERENCES es_resorts(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3EE551564 FOREIGN KEY (operator_id, subresort_id) REFERENCES es_subresorts(operator_id, id) ON DELETE CASCADE;
...

The simple solution would be to fix schema comparator not to signal any changes on columns with columnDefinition properties.
But would be much and much better to add some code to all *SchemaManager#getPortableTableColumnDefinition so they would reconstuct columnDefinition and they would be matched in the schema comparator.

I can do this



 Comments   
Comment by Roderick Schaefer | We handle IT [ 16/Oct/11 ]

I'm having the same issue on my production webserver, but not on the development webserver. I find that odd. It tries to drop all foreign keys and create them again, although without the CHANGE statement you are referring to, Dmitry.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

This maybe fixable by making a hash out of the column definition and saving it into a database comment.

The Foreign Key problem maybe because of an old MySQL version 5.0.x

Comment by Joe Cai [ 16/Jul/12 ]

@beberlei, sounds good to me. any plan of implementing this?





[DBAL-1099] Unittests for Drizzle Platform Created: 02/Jan/15  Updated: 07/Jan/15  Resolved: 07/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Claudio Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: Drizzle, dbal


 Description   

I've realized that the DrizzlePlatform has no unittests at the moment and it should get some. Usually unittests are a must have and every new code should get their tests. DrizzlePlatform is not a new contribution so I'm wodering why it lacks unittests.

What are the reasons that DrizzlePlatform has no unittests?



 Comments   
Comment by Marco Pivetta [ 02/Jan/15 ]

What are the reasons that DrizzlePlatform has no unittests?

It probably just got in when we weren't strict about tests (nor had CI integration yet)

Comment by Claudio [ 02/Jan/15 ]

Sounds to me like unittests are welcome.

Comment by Benjamin Eberlei [ 02/Jan/15 ]

We should rather be removing Drizzle support in an upcoming version (DBAL 2.6), as the database is not developed anymore.

Comment by Marco Pivetta [ 02/Jan/15 ]

Tests are always very welcome.

Comment by Claudio [ 02/Jan/15 ]

Benjamin Eberlei You're more into never touch DrizzlePlatform again? I didn't know that Drizzle isn't developed anymore and I'm not sure if anyone is even using Drizzle with Doctrine DBAL.

Comment by Claudio [ 07/Jan/15 ]

Since Benjamin Eberlei suggested to remove Drizzle and a PR already exists for that (DBAL-1105) (https://github.com/doctrine/dbal/pull/767), I close this issue.





[DBAL-1101] [GH-763] Add date formatting and from/to unix timestamp conversion Created: 03/Jan/15  Updated: 05/Jan/15  Resolved: 05/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: conversion, date, format, sql, timestamp, unix


 Description   

This issue is created automatically through a Github pull request on behalf of andig:

Url: https://github.com/doctrine/dbal/pull/763

Message:

I'm proposing to add date formatting as well as from/to unix timestamp conversion to DBAL. If this PR is going to find resonance I'd gladly add implementations for SQlite and MySQL.

Please let me know if this is something worth to pursue.



 Comments   
Comment by Doctrine Bot [ 05/Jan/15 ]

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





[DBAL-1086] [GH-750] Store the parameters of the chosen connection when using Master/Slave. Created: 19/Dec/14  Updated: 04/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of xrash:

Url: https://github.com/doctrine/dbal/pull/750

Message:

When using the MasterSlaveConnection, the internal parameters array has a different structure than the usual Connection. This can cause the following methods to fail: getHost(), getPort(), getUsername() and getPassword().

I changed the MasterSlaveConnection so that it stores the parameters of the chosen connection in a private property. With this change, the methods that used to fail can now retrieve the configuration for the actual chosen connection, which is, in my opinion, clearly the expected behavior.

I chose to create a new private property in MasterSlaveConnection instead of inherit the $_params from Connection in order to not cause any confusion by having two different array structures in the same variable at different situations.

I also expanded the tests for this case.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1106] [GH-768] [DBAL-1106] Improve schema introspection performance on Oracle Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, introspection, oracle, performance, schema


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/768

Message:

This PR improves the overall schema introspection performance on Oracle by optimizing some of the `getList*()` method SQL queries in the platform.
Unfortunately Oracle system views are rather slow, especially when joining tables. Using subqueries can improve the execution time a lot.

*Improved queries*

(the times have been measured using an exemplary query from the functional test suite)

`getListTableForeignKeysSQL()`: Down from `~2.33s` to `~0.68s` per query
`getListTableColumnsSQL()`: Down from `~0.49s` to `~0.14s` per query
`getListTableIndexesSQL()`: Down from `~0.5s` to `~0.25s` per query

Overall improvement of `OracleSchemaManagerTest` from `~100s` to `~37.5s`.

I was quite impressed by the performance improvements



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

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

Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1104] [GH-766] [DBAL-1104] Add support for object hydration in oci8 driver Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: driver, fetch, object, oci8, oracle


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/766

Message:

Adds support for fetching data into `\stdClass` objects in `oci8` driver.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

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

Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-446] Type json_array can't be null Created: 13/Feb/13  Updated: 04/Jan/15

Status: Reopened
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3, 2.4.2
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Jan Hruban Assignee: Marco Pivetta
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
is referenced by DBAL-966 [GH-655] json_array columns should re... Resolved

 Description   

Column type json_array can be set to nullable, but if there's null in the database, it is returned as an empty array to PHP.

Null should be returned instead, as that's how the other types behave too.



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

This was fixed in 2.3.3

Comment by Joseph Wynn [ 06/Aug/14 ]

I'm seeing this behaviour again in v2.5.0-BETA3 (6d0b048). If I get time this week I can perform a bisect to figure out when it regressed.

Comment by Joseph Wynn [ 06/Aug/14 ]

Actually I don't think this was a regression; it looks like a fix was never made. I've opened a PR: https://github.com/doctrine/dbal/pull/655

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Marco Pivetta [ 06/Aug/14 ]

Re-opened, as this behavior seems reproducible also in 2.4.x

Comment by Steve Müller [ 06/Aug/14 ]

It was never fixed. That seems to have been a misunderstanding here. As pointed out by Marco Pivetta changing this behaviour is a BC break and can't be fixed before 3.0.

Comment by Nate Bessette [ 04/Jan/15 ]

I spent the time to develop a custom data type to workaround this bug: https://frickenate.com/2014/10/json-data-type-doctrine/ . I can't imagine anybody storing null expecting to receive back an empty array. That would be a fundamental break from the very purpose of the SQL NULL value.





[DBAL-1105] [GH-767] Removed drizzle support. Created: 04/Jan/15  Updated: 04/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kimhemsoe:

Url: https://github.com/doctrine/dbal/pull/767

Message:






[DBAL-1091] [GH-755] Update MysqliStatement to support PDO::FETCH_OBJ Created: 23/Dec/14  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: driver, fetch, mysql, mysqli, object


 Description   

This issue is created automatically through a Github pull request on behalf of gohanman:

Url: https://github.com/doctrine/dbal/pull/755

Message:

Return a simple stdClass object if that fetch type is requested.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1042] [GH-724] Enable PostGIS extension for PostgreSQL tests Created: 10/Nov/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Won't Fix Votes: 0
Labels: extension, pgsql, postgis, postgresql, travis


 Description   

This issue is created automatically through a Github pull request on behalf of jsor:

Url: https://github.com/doctrine/dbal/pull/724

Message:

This is more like a proposal. Since PostGIS is one of the most popular extensions of PostgreSQL, it might be a good idea to enable it on Travis and make sure DBAL works with it.

At the moment, DBAL's Schema Tool does not work with PostGIS because it cannot handle some VIEWS added by PostGIS.

See: https://travis-ci.org/jsor/dbal/jobs/40528527



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1033] [GH-716] Do not TRIM() parentheses around partial indexe conditions Created: 05/Nov/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ddl, index, partial, pgsql, postgresql


 Description   

This issue is created automatically through a Github pull request on behalf of PowerKiKi:

Url: https://github.com/doctrine/dbal/pull/716

Message:

Because PostgreSQL will return the expression with a lot of
parentheses we cannot TRIM() them easily. It is easier and more
correct to adapt to what PostgreSQL returns. That means the declaration
of partial indexes must be updated as follow:

Before:
``options=

{"where": "other_id IS NULL"}

``

After:
``options=

{"where": "(other_id IS NULL)"}

``

And fore more complexe conditions, that would be:
``options=

{"where": "(((id IS NOT NULL) AND (other_id IS NULL)) AND (name IS NULL))"}

``



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1038] [GH-720] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: JSON, array, dbal, type

Issue Links:
Duplicate
is duplicated by DBAL-1037 Type json_array is not consistent wit... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of TerjeBr:

Url: https://github.com/doctrine/dbal/pull/720

Message:

Fields of type json_array are often created as "TEXT NOT NULL", because they are not nullable by default.

If you have an existing table, and you add this field, all existing records will get an empty string as the value of the field and not NULL.
If you try to store a NULL value in that field, the database will convert it to an empty string.

The "convertToPHPValue" method for that type only checks for NULL when it converts NULL to array(), it does not check for an empty string.

The test must be changed to also test for the empty string, or else it behaves differently for when the column is set as nullable or not. And for the most common case, when the default vaule of letting the column be not nullable is used, this "feature" of converting blank values to empty arrays is not working.



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1029] [GH-712] Backporting a fix to allow connection without dbname Created: 31/Oct/14  Updated: 03/Jan/15  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cascade, ddl, foreign-keys, sqlanywhere, sqlserver


 Description   

This issue is created automatically through a Github pull request on behalf of mikeSimonson:

Url: https://github.com/doctrine/dbal/pull/712

Message:

The fix is already in master at
https://github.com/doctrine/dbal/commit/387eb5457498781e24716286a2511f5d030d63fb
but because it has not been backported the functionnality is still broken
for symfony 2.5 for instance.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1082] SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Daniel Chesterton Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, ddl, decimal, float, mysql, schematool, unsigned
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-1083 [GH-749] [DBAL-1082] Fix SchemaTool d... Resolved

 Description   

The schema update tool does not consider the possibility that MySQL double/float fields can be unsigned.

When running the CLI tool, it recognises that the schemas differ but it doesn't add the appropriate 'UNSIGNED' SQL statement. For example when the database is SIGNED but the entity is marked as UNSIGNED, running the tool with --dump-sql will generate SQL similar to below:

ALTER TABLE tablename CHANGE field field DOUBLE PRECISION NOT NULL;

Running this has no effect on the database and subsequent calls will try to run the same SQL.

I have created a pull request in GitHub which fixes the issue.






[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ddl, decimal, float, mysql, unsinged

Issue Links:
Reference
relates to DBAL-1082 SchemaTool does not generate SQL for ... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of dchesterton:

Url: https://github.com/doctrine/dbal/pull/749

Message:



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of flack:

Url: https://github.com/doctrine/dbal/pull/743

Message:

I am not 100% sure, but I think the behavior exposed by this test is one of the factors in DBAL-1063. But even if it wasn't, it is still very confusing that `Table::getIndexes` doesn't return the same thing as `SchemaManager::listTableIndexes` when they are both called on the same table.

I've written the test against the MySQL SM, but I suspect the same might happen with other platforms as well



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1103] [GH-765] Remove PHP 5.3 support Created: 03/Jan/15  Updated: 03/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/765

Message:

Just a suggestion for master (2.6). We should move on.



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1100] [GH-762] PostgreSQL needs explicitly closed connection in functional test Created: 03/Jan/15  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.4.3
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, postgresql, process-isolation, tests


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/762

Message:

The test `Doctrine\Tests\DBAL\Functional\ConnectionTest::testConnectWithoutExplicitDatabaseName` prevents further tests in the suite from being run as the connection hangs around in PostgreSQL.

After this particular test, when the next `DROP DATABASE` is run, the log shows:

> 2015-01-03 00:21:28 PST ERROR: database "doctrine_tests" is being accessed by other users
> 2015-01-03 00:21:28 PST DETAIL: There is 1 other session using the database.
> 2015-01-03 00:21:28 PST STATEMENT: DROP DATABASE doctrine_tests

And the next functional test to be run produces something like:

> 1) Doctrine\Tests\DBAL\Functional\ConnectionTest::testPingDoesTriggersConnect
> Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE DATABASE doctrine_tests':
>
> SQLSTATE[42P04]: Duplicate database: 7 ERROR: database "doctrine_tests" already exists
>
> ...

This is with the following:

  • Debian Linux
  • PHP 5.5.9
  • PostgreSQL 9.3.5
  • PHPUnit 4.0.20
  • Process Isolation = off

Turning process isolation on does resolve the issue, but I assume that shouldn't be required. This doesn't seem to affect Travis.



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-982] [GH-669] Correct schema generation for altering PostgreSQL sequences Created: 25/Aug/14  Updated: 03/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/669

Message:

I wrote a detailed explanation here so it is hopefully easy to follow:

        1. Background

With PostgreSQL there are three states for a column to receive a sequence generator: no generator, an internal shortcut towards generating an auto incrementing sequence (SERIAL), and a manually-created sequence. In its current state, DBAL accepts only a boolean "autoincrement" to its `getAlterTableSql()` method (via the passed-in `TableDiff`).

This results in the following scenario:

  • ORM maps a column to "AUTO" which is treated as a sequence (autoincrement = false)
  • DBAL `PostgreSqlSchemaManager` inspects existing table and notices a sequence (autoincrement = true)
  • Diff logic in `getAlterTableSql()` will always detect that autoincrement has changed, and that the requested value is false, so it will always issue a `DROP DEFAULT` statement

This is clearly a bug, and can be proved via a unit test; run the `AbstractPostgreSqlPlatformTestCase::testAlterSchemaSequenceToSequence` test that I have committed against the current DBAL code and you will see it fail (based on what is currently passed in via the ORM; see Q&A below for detailed explanation).

        1. Solution

There already existed a few references to a not-yet-implemented `sequence` property of a column definition, which would store the name of the sequence being used on the column. This makes sense and allows us to support all three column states with regards to sequence, while also preserving backwards compatibility. The default is always null, so it will result in no changes to functionality on other platforms.

So, this PR:

  • Adds the `Column::_sequence` property
  • Correctly sets that property during the `PostgreSqlSchemaManager::_getPortableTableColumnDefinition` method (it actually was already there, just not being used)
  • Checks the value during the `Comparator::diffColumn` operation
  • Uses the value to more correctly determine when to create/drop a sequence during a schema alter
  • Adds the appropriate unit tests to verify the six different combinations here
        1. Q&A

Is this just an ORM bug? Could the ORM be changed to just set autoincrement = true for the AUTO and SEQUENCE strategies?

This would solve the immediate problem, yes. However, it would leave no possible distinction between the three ORM mapping strategies of AUTO, SEQUENCE, and IDENTITY. Further, it would cause a break in `getAlterTableSql()` because setting autoincrement to true implies that we are using the database-generated identity sequence which has a specific name, thereby removing the ability for a user to define a sequence manually with a custom name and have it be used here. This strategy opens the door for addressing those cases later, and does not cause a BC break today.

This seems incomplete; for example, this still doesn't handle the case where a sequence is requested to change from AUTO to a specifically-named sequence.

That is intentional. I think these other cases could and probably should be handled, but they would require changes to both the DBAL and ORM. For example, we pass a `Sequence` object to the create/alter/drop sequence functions, but we do not pass one to the alter function. As a result, the actual sequence name is not available here, so we would absolutely need to make a more thought-out ORM change to solve this. I think that should be separate work, or it could just be something we do not support.

Won't this still require an ORM change to set the `sequence` property?

Yes, the following needs to be added to the `SchemaTool::gatherColumn` method:

```php
if ($class->isIdGeneratorSequence() && $class->getIdentifierFieldNames() == array($mapping['fieldName']))

{ $options['sequence'] = $class->sequenceGeneratorDefinition['sequenceName']; }

```

However, even without that change, this solves the problem on the DBAL side and opens the door to fixing the ORM to behave correctly here.

How do things behave today and how do we want them to behave with respect to alters?

This is what should happen in each alter scenario:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* Add Sequence; Default to `nextval(seqeuence)` Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* No Change No Change Drop Default

This is what does happen today:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* No Change (Bad) Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* Drop Default (Bad) No Change Drop Default


 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1048] Function based index Created: 20/Nov/14  Updated: 02/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

I would like to create a function-based index, but it does not seem to be possible ATM. The final goal is to be able to have case insensitive string filters with Postgresql without losing performance.

I tried this mapping :

  indexes:
        my_entity_name_index:
            columns: [ LOWER(name) ]

But here is what doctrine answers :

[Doctrine\DBAL\Schema\SchemaException]

There is no column with name 'LOWER(name)' on table 'my_entity'.



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

I don't think that we can provide platform-specific index column name support here.

Comment by Michael Lambert [ 02/Jan/15 ]

To me this problem is caused by the bigger issue of some DBs defaulting to case-sensitive and some to case-insensitive. From my searching I have been unable to find a solution to make doctrine operate the same across different collations/databases.

Perhaps the issue would be better described as:
Doctrine does not provide consistency between case-sensitive and case insensitive collations/databases

IMHO it would be very beneficial if Doctrine implemented some method for consistency.

I'm not sure if this is the right place to go into more detail, so I'll refrain for now.

Comment by Steve Müller [ 02/Jan/15 ]

Could you please clarify a bit on "From my searching I have been unable to find a solution to make doctrine operate the same across different collations/databases."? What exactly is broken in Doctrine? Can you give examples?

Comment by Michael Lambert [ 02/Jan/15 ]

Nothing is broken, it could just be improved. Having said that, I don't think this would be a minor task.

The issue I am having that lead me to this issue is that like in mysql != like in postgres. Mysql like == postgres ilike.

Additionally, postgres requires a citext for case insensitive text, mysql relies on the db/table collation.

The only way to make a case insensitive unique key in postgres (at least as far as I could find) is to use a function based index.

I hope this helps define the scope of the case sensitivity issues that would be somewhat solved by adding a function based index or a method to enforce case sensitivity /insensitivity.

(sorry for any auto correct failures, I'm on a mobile device on a train)





[DBAL-1098] [GH-761] Fixed typo Created: 02/Jan/15  Updated: 02/Jan/15  Resolved: 02/Jan/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: typo


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/761

Message:



 Comments   
Comment by Doctrine Bot [ 02/Jan/15 ]

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





[DBAL-1097] [GH-760] [DBAL-1097] Fix foreign key constraint referential action on Oracle Created: 31/Dec/14  Updated: 01/Jan/15  Resolved: 01/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: action, constraint, fk, foreignkey, noaction, ondelete, oracle, referential, restrict


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/760

Message:

Oracle only supports `CASCADE` and `SET NULL` referential actions for foreign key constraints. It also supports `NO ACTION` but it cannot be declared with an explicit `ON DELETE NO ACTION` clause. The complete clause has to be omitted in order to make it work.
This PR fixes supported referential actions and omits the referential clause if either action `NO ACTION` or `RESTRICT` is set for the foreign key constraint to create.



 Comments   
Comment by Doctrine Bot [ 31/Dec/14 ]

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

Comment by Doctrine Bot [ 01/Jan/15 ]

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





[DBAL-1087] [GH-751] Length of fixed string type (char) is ignored on Postgre schema update Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, postgresql, schemamanager


 Description   

This issue is created automatically through a Github pull request on behalf of SenseException:

Url: https://github.com/doctrine/dbal/pull/751

Message:

This PR should fix an issue for the fixed string type columns using PostgreSQL.

I've created a basic Symfony 2.6. Application and using a PostgreSQL 9.3. database. In this dummy project, I've created the following Entity:

<?php

namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping AS ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="test")
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue
     */
    public $id;

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed" = true})
     */
    public $name;
}

The table is successfully created after a schema update, but when another schema update is executed without any changes to the entity, an ALTER query is executed:

ALTER TABLE test ALTER name TYPE CHAR(2);

After I searched in the code of doctrine dbal, I discovered that the length of the char column is not fetched correctly in `PostgreSqlSchemaManager::_getPortableTableColumnDefinition()`. In my example, length results as `null` and will be later set to 255 in the `Comparator`, which isn't the correct length from the database column. The comparation of the schemas results in a change of char-length.

For simplicity, I extended the if-condition in `PostgreSqlSchemaManager` to:

if (strtolower($tableColumn['type']) === 'varchar' || strtolower($tableColumn['type']) === 'bpchar') {

The fix I've contributed does help to parse the length in my case, but when I look into `PostgreSqlPlatform::initializeDoctrineTypeMappings()` there could be other types with the same problem, that are mapped to the doctrine string type.

// ... part of PostgreSqlPlatform::initializeDoctrineTypeMappings()
            'varchar'       => 'string',
            'interval'      => 'string',
            '_varchar'      => 'string',
            'char'          => 'string',
            'bpchar'        => 'string',
            'inet'          => 'string',

I guess we need to cover `char` and the others too.

`PostgreSqlSchemaManagerTest` also doesn't cover existing code. How is this going to be tested? Does the SchemaManagers need some tests in general?



 Comments   
Comment by Doctrine Bot [ 31/Dec/14 ]

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





[DBAL-1088] [GH-752] Fix error handling restore Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, error, handler, mysqli


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

Url: https://github.com/doctrine/dbal/pull/752

Message:

PHP already handles an internal stack of error handlers



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

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

Comment by Doctrine Bot [ 31/Dec/14 ]

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





[DBAL-1084] MySQL DateTime fractional seconds exception Created: 18/Dec/14  Updated: 31/Dec/14

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

Type: New Feature Priority: Major
Reporter: Jachim Coudenys Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL 5.6.4+



 Description   

Since MySQL 5.6.4 it is possible to include fractional seconds in datetime/timestamp fields.

Doctrine cannot handle this at the moment, and it is not clear how this can be resolved.

Doctrine\DBAL\Types\ConversionException(#67): Could not convert database value "2014-12-16 17:06:38.385" to Doctrine Type datetime. Expected format: Y-m-d H:i:s
  #0 /var/www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php(67): Doctrine\DBAL\Types\ConversionException::conversionFailedFormat('2014-12-16 17:0...', 'datetime', 'Y-m-d H:i:s')
  #1 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(330): Doctrine\DBAL\Types\DateTimeType->convertToPHPValue('2014-12-16 17:0...', Object(Doctrine\DBAL\Platforms\MySqlPlatform))
  #2 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(359): Doctrine\ORM\Internal\Hydration\AbstractHydrator->gatherRowData(Array, Array, Array, Array)
  #3 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(179): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData(Array, Array, Array)
  #4 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(140): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData()
  #5 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(804): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll(Object(Doctrine\DBAL\Driver\PDOStatement), Object(Doctrine\ORM\Query\ResultSetMapping), Array)
  #6 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(574): Doctrine\ORM\AbstractQuery->execute(NULL, 1)
  #7 /var/www/index.php(142): Doctrine\ORM\AbstractQuery->getResult()

The solution for MsSQL (see DBAL-860) cannot be used, because the fractional seconds definition can be different across fields:

  `insert` timestamp NULL DEFAULT NULL,
  `update` timestamp(3) NULL DEFAULT NULL,
  `delete` timestamp(5) NULL DEFAULT NULL,

My current approach is to create a custom type, but I would like to create a solution in Doctrine.

Any thoughts on this?



 Comments   
Comment by Marco Pivetta [ 18/Dec/14 ]

We don't currently support this nor can support a change in the DateTime type in 2.x. If you want support for this, then I suggest using a custom type (as you are doing) or proposing something new for 3.x

Comment by Jachim Coudenys [ 19/Dec/14 ]

For anyone that is having the same issue, I've added my version of the custom mapping in a Github Gist.

Comment by Steve Müller [ 24/Dec/14 ]

Jachim Coudenys can you please check if it fixes your issue if you adopted this:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLAnywherePlatform.php#L495-L501

to MysqlPlatform? Because it is basically the same issue. I currently don't have a MySQL 5.6 setup so I cannot test it on my machine.

Comment by Jachim Coudenys [ 31/Dec/14 ]

Steve Müller I think I tried that in the beginning, but normal fields threw errors. I will try it on a VM the following days.





[DBAL-999] Get a Sql Server error on Order By - Symfony2 Created: 08/Oct/14  Updated: 31/Dec/14

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

Type: Bug Priority: Major
Reporter: Maël SOURISSEAU Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orderBy, query, sqlserver


 Description   

Using Symfony with Sql Server and from what I've read, it seems that the connection to the database is not stable.

As soon as I use the orderBy method I get an error :

Here's an example :

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
  $qStores =
        $this->getManager()
             ->createQueryBuilder()
             ->select('rpdv')
             ->from('MainBundle:PointDeVenteReference', 'rpdv')
             ->andWhere( 'rpdv.partenaireClient = :id_partner ' )
                 ->setParameter( 'id_partner', $this->getUser()->getPartenaire()->getIdPartenaire() )
             ->orderBy( 'rpdv.idPointDeVenteReference' , 'DESC' )
             ->setFirstResult( 0 )
             ->setMaxResults( 30 );

And the error :

An exception has been thrown during the rendering of a template ("An exception occurred while executing
'SELECT DISTINCT TOP 30 id_point_de_vente_reference0
FROM ( SELECT p0_.id_point_de_vente_reference AS id_point_de_vente_reference0,
p0_.reference AS reference1,
p0_.date_derniere_modification AS date_derniere_modification2,
p0_.blocage AS blocage3
FROM point_de_vente_reference p0_
WHERE p0_.id_partenaire_client = ?
ORDER BY p0_.id_point_de_vente_reference DESC ) dctrn_result
ORDER BY id_point_de_vente_reference0 DESC'
with params [2829]:SQLSTATE[42000]:
[Microsoft][SQL Server Native Client 11.0][SQL Server]
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions,
unless TOP, OFFSET or FOR XML is also specified.") in MainBundle:Default:store/list.html.twig at line 79.
I tried to change the class SQLServerPlatform with corrections found on the net, without success.

Do you have any idea?

Thx !



 Comments   
Comment by Steve Müller [ 08/Oct/14 ]

Which version of DBAL are you using? A lot of fixes have been applied to SQL Server's LIMIT/OFFSET query rewriting in DBAL during the last months.

Comment by Maël SOURISSEAU [ 08/Oct/14 ]

2.4 for DBAL.

Under my request, I have :

$stores = new Paginator( $qStores, TRUE );

In passing the second parameter to FALSE, I have no error.

Comment by Marco Pivetta [ 19/Oct/14 ]

I'd suggest checking ORM+DBAL latest to see if the issue still exists, as those component have suffered from radical changes in the last few months.

Comment by Maël SOURISSEAU [ 29/Dec/14 ]

I currently still have the anomaly with the following configuration :

"doctrine/doctrine-bundle": "1.3.*@dev"
"doctrine/dbal": "~2.5"
"doctrine/orm": "~2.4"

Comment by Maël SOURISSEAU [ 29/Dec/14 ]

The problem apparently comes from the class SQLServerPlatform (doModifyLimitQuery)

Comment by Marco Pivetta [ 29/Dec/14 ]

Maël SOURISSEAU that kind of information is insufficient: please pick exact versions from your composer.lock instead.

Comment by Maël SOURISSEAU [ 30/Dec/14 ]
Unable to find source-code formatter for language: json. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
...
{
    "name": "doctrine/dbal",
    "version": "v2.5.0",
    "source": {
        "type": "git",
        "url": "https://github.com/doctrine/dbal.git",
        "reference": "71140662c0a954602e81271667b6e03d9f53ea34"
    },
    "dist": {
        "type": "zip",
        "url": "https://api.github.com/repos/doctrine/dbal/zipball/71140662c0a954602e81271667b6e03d9f53ea34",
        "reference": "71140662c0a954602e81271667b6e03d9f53ea34",
        "shasum": ""
    },
    "require": {
        "doctrine/common": ">=2.4,<2.6-dev",
        "php": ">=5.3.2"
    },
    "require-dev": {
        "phpunit/phpunit": "4.*",
        "symfony/console": "2.*"
    },
    "suggest": {
        "symfony/console": "For helpful console commands such as SQL execution and import of files."
    },
    "bin": [
        "bin/doctrine-dbal"
    ],
    "type": "library",
    "extra": {
        "branch-alias": {
            "dev-master": "2.5.x-dev"
        }
    },
    "autoload": {
        "psr-0": {
            "Doctrine\\DBAL\\": "lib/"
        }
    },
    "notification-url": "https://packagist.org/downloads/",
    "license": [
        "MIT"
    ],
    "authors": [
        {
            "name": "Roman Borschel",
            "email": "roman@code-factory.org"
        },
        {
            "name": "Benjamin Eberlei",
            "email": "kontakt@beberlei.de"
        },
        {
            "name": "Guilherme Blanco",
            "email": "guilhermeblanco@gmail.com"
        },
        {
            "name": "Jonathan Wage",
            "email": "jonwage@gmail.com"
        }
    ],
    "description": "Database Abstraction Layer",
    "homepage": "http://www.doctrine-project.org",
    "keywords": [
        "database",
        "dbal",
        "persistence",
        "queryobject"
    ],
    "time": "2014-12-04 21:57:15"
},
{
    "name": "doctrine/doctrine-bundle",
    "version": "dev-master",
    "source": {
        "type": "git",
        "url": "https://github.com/doctrine/DoctrineBundle.git",
        "reference": "3beb3a780485ab01f86941f4892cd23ef8c39c6b"
    },
    "dist": {
        "type": "zip",
        "url": "https://api.github.com/repos/doctrine/DoctrineBundle/zipball/3beb3a780485ab01f86941f4892cd23ef8c39c6b",
        "reference": "3beb3a780485ab01f86941f4892cd23ef8c39c6b",
        "shasum": ""
    },
    "require": {
        "doctrine/dbal": "~2.3",
        "doctrine/doctrine-cache-bundle": "~1.0",
        "jdorn/sql-formatter": "~1.1",
        "php": ">=5.3.2",
        "symfony/doctrine-bridge": "~2.2",
        "symfony/framework-bundle": "~2.2"
    },
    "require-dev": {
        "doctrine/orm": "~2.3",
        "phpunit/php-code-coverage": "~1.2",
        "phpunit/phpunit": "~3.7",
        "phpunit/phpunit-mock-objects": "~1.2",
        "satooshi/php-coveralls": "~0.6.1",
        "symfony/validator": "~2.2",
        "symfony/yaml": "~2.2",
        "twig/twig": "~1"
    },
    "suggest": {
        "doctrine/orm": "The Doctrine ORM integration is optional in the bundle.",
        "symfony/web-profiler-bundle": "to use the data collector"
    },
    "type": "symfony-bundle",
    "extra": {
        "branch-alias": {
            "dev-master": "1.3.x-dev"
        }
    },
    "autoload": {
        "psr-4": {
            "Doctrine\\Bundle\\DoctrineBundle\\": ""
        }
    },
    "notification-url": "https://packagist.org/downloads/",
    "license": [
        "MIT"
    ],
    "authors": [
        {
            "name": "Symfony Community",
            "homepage": "http://symfony.com/contributors"
        },
        {
            "name": "Benjamin Eberlei",
            "email": "kontakt@beberlei.de"
        },
        {
            "name": "Doctrine Project",
            "homepage": "http://www.doctrine-project.org/"
        },
        {
            "name": "Fabien Potencier",
            "email": "fabien@symfony.com"
        }
    ],
    "description": "Symfony DoctrineBundle",
    "homepage": "http://www.doctrine-project.org",
    "keywords": [
        "database",
        "dbal",
        "orm",
        "persistence"
    ],
    "time": "2014-11-28 08:32:03"
},
{
    "name": "doctrine/orm",
    "version": "v2.4.7",
    "source": {
        "type": "git",
        "url": "https://github.com/doctrine/doctrine2.git",
        "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68"
    },
    "dist": {
        "type": "zip",
        "url": "https://api.github.com/repos/doctrine/doctrine2/zipball/2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
        "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
        "shasum": ""
    },
    "require": {
        "doctrine/collections": "~1.1",
        "doctrine/dbal": "~2.4",
        "ext-pdo": "*",
        "php": ">=5.3.2",
        "symfony/console": "~2.0"
    },
    "require-dev": {
        "satooshi/php-coveralls": "dev-master",
        "symfony/yaml": "~2.1"
    },
    "suggest": {
        "symfony/yaml": "If you want to use YAML Metadata Mapping Driver"
    },
    "bin": [
        "bin/doctrine",
        "bin/doctrine.php"
    ],
    "type": "library",
    "extra": {
        "branch-alias": {
            "dev-master": "2.4.x-dev"
        }
    },
    "autoload": {
        "psr-0": {
            "Doctrine\\ORM\\": "lib/"
        }
    },
    "notification-url": "https://packagist.org/downloads/",
    "license": [
        "MIT"
    ],
    "authors": [
        {
            "name": "Roman Borschel",
            "email": "roman@code-factory.org"
        },
        {
            "name": "Benjamin Eberlei",
            "email": "kontakt@beberlei.de"
        },
        {
            "name": "Guilherme Blanco",
            "email": "guilhermeblanco@gmail.com"
        },
        {
            "name": "Jonathan Wage",
            "email": "jonwage@gmail.com"
        }
    ],
    "description": "Object-Relational-Mapper for PHP",
    "homepage": "http://www.doctrine-project.org",
    "keywords": [
        "database",
        "orm"
    ],
    "time": "2014-12-16 13:45:01"
},
...
Comment by Steve Müller [ 31/Dec/14 ]

I think this issue is being dealt with in this PR: https://github.com/doctrine/doctrine2/pull/1220
It's basically an issue with the ORM paginator because it uses the ORDER BY clause in the derived table which is invalid in SQL Server.





[DBAL-562] [GH-345] Prevent autoincrement columns from creating CREATE SEQUENCE statement Created: 19/Jul/13  Updated: 31/Dec/14  Resolved: 22/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of chEbba:

Url: https://github.com/doctrine/dbal/pull/345

Message:

Related to DDC-1657 doctrine/dbal@79e894b
Add autoincrement sequence check for new sequences



 Comments   
Comment by Doctrine Bot [ 19/Dec/13 ]

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

Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by Doctrine Bot [ 31/Dec/14 ]

A related Github Pull-Request [GH-345] was assigned:
https://github.com/doctrine/common/pull/345





[DBAL-836] [GH-543] Clauses LEFT OUTER JOIN and RIGHT OUTER JOIN Created: 13/Mar/14  Updated: 30/Dec/14  Resolved: 14/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of italodom:

Url: https://github.com/doctrine/dbal/pull/543

Message:

Added methods for construction of clauses LEFT OUTER JOIN and RIGHT OUTER JOIN



 Comments   
Comment by Doctrine Bot [ 14/Mar/14 ]

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

Comment by Doctrine Bot [ 30/Dec/14 ]

A related Github Pull-Request [GH-543] was assigned:
https://github.com/doctrine/doctrine2/pull/543





[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 29/Dec/14

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

Type: Bug Priority: Major
Reporter: Maciej Grajcarek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, dql, orderBy, sqlserver
Environment:

Windows



 Description   

Hi!
I have a problem with Query results limit when ordering by SUM of a field.

My query looks like this:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

First I was catching following error:
message: "[Syntax Error] line 0, col 395: Error: Expected known function, got 'SUM'"
class: Doctrine\ORM\Query\QueryException

It only accourse if SUM is used in ORDER BY clause.

I have registered new class Sum which extends FunctionNode.

Now, query is build and executed but it has an error:

'SELECT * FROM 
     (SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY value) DESC) AS doctrine_rownum FROM yellowpage_keywords y0_ INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id INNER JOIN listings l2_ ON y1_.listing_id = l2_.id WHERE l2_.customer_id = ? AND y0_.origin_date >= ? AND y0_.origin_date <= ? GROUP BY y0_.name_crc, y0_.name) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10 ORDER BY doctrine_rownum' with params ["111", "2013-01-01 00:00:00.000000", "2014-12-31 23:59:59.000000"]

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC)

In doModifyLimitQuery method I have modified:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', $column['table'], $column['column']);

to:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', str_replace('(', '\(', $column['table']), str_replace(')', '\)', $column['column']));

Now preg_match founds matching strings and OVER part of query is build correctly.

I checked other issues about this problem (which are marked as already fixed) and I have no idea why it's not working for me.

Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 17/Dec/14 ]

Seems like a bit of information is missing: Is this issue related to the paginator API or not?

Comment by Maciej Grajcarek [ 17/Dec/14 ]

First of all - thank you for formatting my issue.
Secondly yes - issue is directly connected with paginator API.

Here is a code which should help you to replicate the problem:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

        $dql = $this->getEntityManager()->createQuery($query);
        $dql
            ->setParameter('customerId', $customerId)
            ->setParameter('dateFrom', $dateFrom)
            ->setParameter('dateTo', $dateTo);
        $dql->setMaxResults(10);    

        $keywords = $dql->getArrayResult(); 
Comment by Marco Pivetta [ 17/Dec/14 ]

That doesn't involve the paginator, just DQL.

SUM() and computed values are not supported in the ORDER BY clause: you have to select them first. Try:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY total DESC
Comment by Maciej Grajcarek [ 18/Dec/14 ]

If I will do it, it will result in a following query:

SELECT *
FROM (
	SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum 
	FROM yellowpage_keywords y0_
	INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id
	INNER JOIN listings l2_ ON y1_.listing_id = l2_.id
	WHERE l2_.customer_id = 111
		AND y0_.origin_date >= '2014-01-01'
		AND y0_.origin_date <= '2014-12-01'
	GROUP BY y0_.name_crc, y0_.name
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 10
ORDER BY doctrine_rownum

It's an incorrect query for an SQL Server. Take a look on this part:

ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC) AS doctrine_rownum

It looks like this is the copy of this issue: http://www.doctrine-project.org/jira/browse/DBAL-788
I'm on doctrine version 2.5 which has patch from that issue included, but I have no idea why it's not working for me.

Comment by Steve Müller [ 24/Dec/14 ]

Maciej Grajcarek looks like it is an issue with your SUM function implementation. If you change your DQL to use ORDER BY COUNT(ypk.value) instead of ORDER BY SUM(ypk.value), does it work then? If so, there is something wrong with your SUM function and therefore not an issue with DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

well forget about it I think I am wrong here.

Comment by Maciej Grajcarek [ 29/Dec/14 ]

Hi,
I will try to use COUNT as soon as I will be able to do that.

But I already tried other aggregation functions before and the result was exactly the same.





[DBAL-1095] [GH-759] [DBAL-1095] Fix index introspection on SQL Anywhere Created: 28/Dec/14  Updated: 28/Dec/14  Resolved: 28/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: foreignkey, index, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/759

Message:

SQL Anywhere creates indexes implicitly for foreign key constraints. Thoses should not be introspected by the schema manager to avoid unnecessary schema updates with ORM's schema tool. DBAL already creates indexes for foreign key constraints implicitly...



 Comments   
Comment by Doctrine Bot [ 28/Dec/14 ]

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

Comment by Doctrine Bot [ 28/Dec/14 ]

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





[DBAL-947] [GH-634] Transaction object definition Created: 21/Jul/14  Updated: 28/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2279 [GH-571] Update lib/Doctrine/ORM/Enti... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/634

Message:

To move forward with the Transaction Object, here is an alternative proposal to #571.

This keeps the same basic idea, but now `createTransaction()` returns a `TransactionDefinition` object, which is configurable, and has a `begin()` method that starts the underlying transaction and returns the `Transaction` object:

$tx = $em->createTransaction() // TransactionDefinition
->withIsolationLevel(Connection::TRANSACTION_SERIALIZABLE) // TransactionDefinition
->begin(); // Transaction

I think that this implementation checks all the boxes:

  • Clear separation between the Transaction and its Definition
  • Once the Transaction is created, its Definition is set and cannot be changed
  • No risk to forget to call `begin()`: if you do, you'll deal with a TransactionDefinition and just get a call to undefined method if you try to `commit()` it. Plus, your IDE will be able to warn you while coding.

And needless to say, we're still keeping 100% BC compatibility.

What do you think?



 Comments   
Comment by Doctrine Bot [ 28/Dec/14 ]

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





[DBAL-1094] [GH-758] Cleanup travis database creation Created: 26/Dec/14  Updated: 27/Dec/14  Resolved: 27/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: travis


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/758

Message:

Remove database creation from Travis build script because it is actually done by DBAL test suite already. Moreover it avoids creating temp databases which are useless and not even used by PostgreSQL currently.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by Doctrine Bot [ 27/Dec/14 ]

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





[DBAL-1092] [GH-756] [DBAL-1062] Fix renaming indexes used by foreign key constraints Created: 24/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: index, rename

Issue Links:
Reference
relates to DBAL-1062 upgrade from v2.4.3 to v2.5.0 is forc... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/756

Message:

Platforms that do not support a SQL syntax for natively renaming indexes need to drop and recreate indexes to perform a rename.
Platforms like MySQL < 5.7 deny dropping indexes used by foreign key constraints. In this case foreign key constraints have to be dropped before dropping indexes and have to be recreated after the particular index(es) have been recreated.
This is a major issue right now for people trying to upgrade to DBAL 2.5.



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

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

Comment by Doctrine Bot [ 26/Dec/14 ]

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





[DBAL-1090] [GH-754] Changing string to fixed string is not recognized in PostgreSQL Platform Created: 21/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, postgresql


 Description   

This issue is created automatically through a Github pull request on behalf of SenseException:

Url: https://github.com/doctrine/dbal/pull/754

Message:

The following change of an entity using PostgreSQL is not recognized by Doctrine DBAL:
from

    /**
     * @ORM\Column(type="string", name="name", length=2)
     */
    public $name;

to

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed"=true})
     */
    public $name;

A schema-update should change the column from `character varying(2)` to `character(2)` but instead acts like no changes were made on the column.

With this PR, I've extended the `PostgreSqlPlatform` to detect changes of the fixed option of a column.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

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





[DBAL-560] [GH-344] Fix Limit with order by on SQL Server 2008 R2 Created: 17/Jul/13  Updated: 25/Dec/14  Resolved: 16/Nov/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of micheletedeschi:

Url: https://github.com/doctrine/dbal/pull/344

Message:

Fix Limit with order by on SQL Server 2008 R2

Found problem when using this bundle:

  • cedriclombardot/admingenerator-generator-bundle
  • jms/job-queue-bundle

This fix resolve the problem of wrong column name on ROW_NUMBER() OVER.

Tested on:

  • SQL Server 2008 R2
  • php_pdo_sqlsrv_54
  • Symfony 2.3.2
  • Doctrine 2.4.0 RC2

Now work paging and paging with order by.



 Comments   
Comment by Doctrine Bot [ 04/Oct/13 ]

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

Comment by Fabio B. Silva [ 16/Nov/13 ]

Closed.. see https://github.com/doctrine/dbal/pull/344 for more details...

Comment by Doctrine Bot [ 25/Dec/14 ]

A related Github Pull-Request [GH-344] was assigned:
https://github.com/doctrine/common/pull/344

Comment by Doctrine Bot [ 25/Dec/14 ]

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





[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: detection, mariadb, mysql, platform, version


 Description   

This issue is created automatically through a Github pull request on behalf of nlegoff:

Url: https://github.com/doctrine/dbal/pull/742

Message:

Hi,
After upgrading to DBAL 2.5, I got an issue where I could not rename index while migrating because of MariaDB [versioning](http://en.wikipedia.org/wiki/MariaDB#Versioning) which outputs ```10.0.15-MariaDB-1~wheezy ``` as server version.

Because 10.x > 5.7 it loads new features from mysql 5.7 which are not available in mariadb ..



 Comments   
Comment by Doctrine Bot [ 13/Dec/14 ]

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

Comment by Doctrine Bot [ 24/Dec/14 ]

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





[DBAL-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785



 Comments   
Comment by Steve Müller [ 24/Dec/14 ]

Nicolas Vanheuverzwijn I think you will have to mark your custom type as requiring a SQL comment, otherwise the schema manager cannot distinguish between DateTime type and your custom type because both map to the same native SQL type. See here:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

You will have to add the following to your custom type implementation:

/**
 * {@inheritdoc}
 */
public function requiresSQLCommentHint(AbstractPlatform $platform)
{
    return true;
}

Also I think it might be required to give your custom type a distinct name like:

/**
 * {@inheritdoc}
 */
public function getName()
{
    return 'datetime_utc';
}
Comment by Steve Müller [ 24/Dec/14 ]

See also: http://doctrine-orm.readthedocs.org/en/latest/cookbook/custom-mapping-types.html

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Wow, I shall take a look at this. This might be it ! Thanks a lot for your reply.

Comment by Steve Müller [ 24/Dec/14 ]

You're welcome. Can you please report if that fixed your problem so we can closse the issue eventually? Thanks.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Yes sir. The problem I have was that I am using doctrine 2.2. I shall migrate my stuff to doctrine 2.5 and use that feature.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

This feature is implemented in version >=2.3 of Doctrine/DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

Yes. 2.2 is EOL anyways and I think 2.3 is now only getting security fixes so an upgrade to at least 2.4 is highly recommended.





[DBAL-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3, 2.4, 2.5
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, offset, orderby, server, sql, sqlserver, sqlsrv


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/dbal/pull/745

Message:

SQL Server 2012 introduced new syntax for paging records using the OFFSET... FETCH clause. See http://technet.microsoft.com/en-us/library/gg699618%28v=sql.110%29.aspx for details on the specification.

This pull request:

  • Adds doModifyLimitQuery specific to SQLServer2012Platform, using OFFSET ... FETCH instead of ROW_NUMBER() OVER(blah blah)
  • Duplicates tests from SQLServerPlatformTest, using simpler OFFSET ... FETCH syntax

This version of doModifyLimitQuery will be much more robust than the one for SQLServer 2008 and below.



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

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





[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
is referenced by DBAL-1080 [GH-748] minor phpdoc fixes in the re... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/747

Message:

Some minor phpcs fixes in the dbal schema files



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

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





[DBAL-1078] [GH-746] minor phpdoc fixes in the platform files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: code, cs, docblock, style


 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/746

Message:

Some minor phpcs fixes in the dbal platform files



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DBAL-1075] [GH-744] Removed non-phpdoc @internal tags Created: 15/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5, 2.4.3
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: annotation, docblock


 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/744

Message:

Removed 2 @internal phpdoc tags as they were about old internal api usage and these methods are public api as @beberlei & @Ocramius confirmed on irc #doctrine

> ocramius: the @internal are old comments that were used to tell information about internal API usage
> ocramius: they are not the @internal of phpdoc, so you are welcome to send a PR to fix that



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DBAL-1071] [GH-740] Add 2.5 status to README Created: 11/Dec/14  Updated: 24/Dec/14  Resolved: 11/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5, 2.5.1
Fix Version/s: 2.6
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: badges, travis


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/740

Message:



 Comments   
Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Doctrine Bot [ 11/Dec/14 ]

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





[DBAL-1080] [GH-748] minor phpdoc fixes in the remaining files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 19/Dec/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
relates to DBAL-1079 [GH-747] minor phpdoc fixes in the sc... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/748

Message:

This pr fixes the remaining phpcs issues left after #746 & #747



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

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





[DBAL-1089] [GH-753] Add a unit test for broken backslashes on MySQL in LIKE Created: 19/Dec/14  Updated: 19/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nickvergessen:

Url: https://github.com/doctrine/dbal/pull/753

Message:






[DBAL-1077] Query limit for sql server Created: 16/Dec/14  Updated: 16/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: yannick LE LAN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, regex, sqlserver
Environment:

sql server



 Description   

On branch master: tests/Doctrine/Tests/DBAL/platforms/AbstractSQLServerPlatformTestCase.php
On branch 2.4: tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php

public function testModifyLimitQueryFolcoerr()
{

    $sql = $this->_platform->modifyLimitQuery('SELECT son.label AS Name FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0 ORDER BY son.identifier DESC', 1, 0);

    $this->assertEquals('SELECT * FROM (SELECT son.label AS Name, ROW_NUMBER() OVER (ORDER BY son.identifier DESC) AS doctrine_rownum FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum', $sql);

}

Correction proposed:
on both branches: lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

protected function doModifyLimitQuery(...)
{
    ...

    #ACTUAL: 
    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/i';

#CORRECT:

    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/iU';

explanation: "/U" pattern modifier => http://php.net/manual/en/reference.pcre.pattern.modifiers.php
Ungreedy behavior not susceptible to fall on ?! negative lookahead on parenthesis hunger

  1. has impacts on ORM with setMaxResults (which was failing in my case and made me investigate)


 Comments   
Comment by Marco Pivetta [ 16/Dec/14 ]

Can you send a PR for this change instead?

Comment by yannick LE LAN [ 16/Dec/14 ]

I will do so by the end of the week,





[DBAL-1068] Microsoft SQL Server issues with ANSI_NULLS=OFF Created: 09/Dec/14  Updated: 13/Dec/14  Resolved: 13/Dec/14

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

Type: Bug Priority: Critical
Reporter: man4red Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Microsoft SQL Server 2012 (11.0.5058)

zf2, doctrine2, skeletonApplication, + modules
zf-commons/zfc-base v0.1.2
zf-commons/zfc-user 1.2.1
zf-commons/zfc-user-doctrine-orm dev-master
bjyoungblood/bjy-authorize dev-master


Attachments: PNG File bug1.png     PNG File bug2.png    

 Description   

So here what I have (see my Environment for more details)

$modules = array(
    'Application', //skeleton
    'DoctrineModule',
    'DoctrineORMModule',
    'DoctrineDataFixtureModule',
    'ZfcBase',
    'ZfcUser',
    'ZfcUserDoctrineORM',
    'BjyAuthorize',
    'User', // Entity copied from BjyAuthorize vendor folder
);
//module/User/Entity/User.php (copied from vendor\bjyoungblood\bjy-authorize\data\User.php.dist)
...
    /**
     * @var string
     * @ORM\Column(type="string", length=255, unique=true, nullable=true)
     */
    protected $username;
...
./vendor/doctrine/doctrine-module/bin/doctrine-module orm:schema-tool:create --dump-sql
CREATE TABLE [users] (id INT IDENTITY NOT NULL, username NVARCHAR(255), email NVARCHAR(255) NOT NULL, displayName NVARCHAR(50), password NVARCHAR(128) NOT NULL, state INT NOT NULL, PRIMARY KEY (id));
CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL;
...
and so on...

on create

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 Cannot create index. Object 'users' was created with the following SET options off: 'ANSI_NULLS'. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E06
77 ON [users] (username) WHERE username IS NOT NULL
....

Maybe this helps:

My database created in MSSQL and has default option ANSI_NULLS = OFF

see my options (bug1.png)

ok, changed it to ANSI_NULLS = ON according to documentation (but for now this sets OFF by default on create database)

got a new exception

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query noti
fications and/or XML data type methods and/or spatial index operations. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL

Then I copied to Microsoft SQL Management Studio code above.
No error!

Then I chcked off this checkbox in SQL Management Studio
(see bug2.png)

and SQL query now failed with almost the same error, but now in Management Studio!

Msg 1934, Level 16, State 1, Line 2
CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.

So it seems that problem starts when we set for username unique=true and using MSSQL that trying to create UNIQUE INDEX ... WHERE fieled IS NOT NULL

Some related topics:
ANSI_NULLS
CONCAT_NULL_YIELDS_NULL
ANSI_WARNINGS
ANSI_PADDING
Creating a unique constraint that ignores nulls in SQL Server

Going to move my project to MySQL if this bug are not my fault



 Comments   
Comment by Steve Müller [ 12/Dec/14 ]

This is nothing we can control in Doctrine. According to the documentation http://msdn.microsoft.com/en-us/library/ms189292.aspx there are some requirements server-side that have to be met in order for such unique constraints to work. You will have to configure your server properly.

Comment by man4red [ 12/Dec/14 ]

Yep, thx for answer, but according to the same documentation:

The ANSI_NULLS connection-level option must be set to ON when the CREATE TABLE or ALTER TABLE statement that defines the computed column is executed. The OBJECTPROPERTY function reports whether the option is on through the IsAnsiNullsOn property.

The connection on which the index is created, and all connections trying INSERT, UPDATE, or DELETE statements that will change values in the index, must have six SET options set to ON and one option set to OFF. The optimizer ignores an index on a computed column for any SELECT statement executed by a connection that does not have these same option settings.
The NUMERIC_ROUNDABORT option must be set to OFF, and the following options must be set to ON:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
Setting ANSI_WARNINGS to ON implicitly sets ARITHABORT to ON when the database compatibility level is set to 90 or higher.

So my fixtures are created without correct connection-level option

Am I wrong?

Comment by man4red [ 12/Dec/14 ]

I think that problem is still persist.
According to documentation connection must have some options (see http://msdn.microsoft.com/en-us/library/ms189292.aspx and my comment)

Propose to pay more attention to the problem.

Comment by Steve Müller [ 12/Dec/14 ]

Hmmm I suppose that there is something wrong with your setup/configuration then. I just tested this using DBAL + sqlsrv driver + SQL Server 2012 and it adds the unique index on a nullable column without problems. Not sure what's wrong with your client/server setup then. Also I don't see how one would set those settings in the connection handle...
Which database driver are you using? sqlsrv or pdo_sqlsrv?

Comment by man4red [ 12/Dec/14 ]

Sorry for bothering you/
Now I began to suspect that the case in the client
I'll test today booth setup on a diffirent clients

Comment by Steve Müller [ 12/Dec/14 ]

Nevermind
If there truly is a bug we'll fix that somehow but as this is really common core functionality and nobody complained so far I suppose it's really related to your environment. Please let me know if I can close the issue as soon as you have checked your env.
Thanks!

Comment by man4red [ 12/Dec/14 ]

Steve, it seems, that problem persist only with FreeTDS/dblib driver (my env). Probably sqlsrv driver does set this parameters automatically.
Unfortunately there is no other mssql drivers for linux, so situation is very strange. Maybe there is nobody using linux + mssql env? Crzy Also forced to move to pdo_mysql.

Untill dblib not supported for doctrine - we can mark this as invalid.
Thx for your help

Comment by man4red [ 12/Dec/14 ]

Am I right at conclusion that:
1. Linux users can use dblib+mssql and had this issues. To fix this they can set connection-level paramters somehow before ALTER TABLE by querying "SET ANSI_NULLS ON; SET ANSI_PADDING ON; ..." etc...
2. There is only windows users are able to use doctrine DBAL with mssql without any problems thru sqlsrv driver provided by microsoft?
it bothers me in some way

Comment by Steve Müller [ 13/Dec/14 ]

Hehe we could have saved a lot of time if you had mentioned earlier that your are using dblib driver
But nevermind. dblib is not supported by Doctrine as it is an experimental driver and quite buggy. Not even sure how you managed to get DBAL connecting through dblib without a custom driver implementation. Whatsoever, unfortunately you are right, there currently is no officially supported way of connecting with DBAL to a SQL Server using a linux client. And yes only Windows users can do that by using either pdo_sqlsrv or native sqlsrv drivers provided by M$
If you are not bound to a Microsoft SQL Server backend and can use an alternative such as MySQL or any other database vendor I would then advise you to do that. I highly discourage you to start messing with dblib and its bugs/incompatibilities. If you are really bound to SQL Server you'll have to let your PHP application run on a windows machine and utilize one of Microsoft's PHP drivers. Hope that helps for now...
Closing then...





[DBAL-1051] [GH-730] Update index name quoting in MySQL table creation Created: 28/Nov/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1072 [GH-741] [DBAL-1051] Quote index name... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of garoevans:

Url: https://github.com/doctrine/dbal/pull/730

Message:

When creating a table that includes an index named with a reserved keyword the index name isn't quoted. When creating the index specifically the name is quote. This bring the table generation SQL inline with the index generation.



 Comments   
Comment by Doctrine Bot [ 29/Nov/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DBAL-1072] [GH-741] [DBAL-1051] Quote index name in inline index declaration SQL Created: 12/Dec/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1051 [GH-730] Update index name quoting in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/741

Message:

Supersedes #730

  • Improved test case
  • Fixed quoting for SQL Anywhere
  • Throw exception in DB2 platform for unsupported inline index declarations


 Comments   
Comment by Doctrine Bot [ 12/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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

Comment by Steve Müller [ 12/Dec/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/558cbf172cb04a9d9df3e11f3425ddf9308e0a81





[DBAL-1070] AzureSQL specificities are not taken into account Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.4.3

Type: Bug Priority: Major
Reporter: Nicolas Séverin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: azure, dbal, sqlserver
Environment:

Azure website using an AzureSQL database (based on SQL Server 2012).



 Description   

In Azure SQL, table ‘sys.extended_properties’ does not exist.
But SQLAzurePlatform inherits from class SQLServerPlatform, which uses it.
The code in question is here /Doctrine/DBAL/Platforms/SQLServerPlatform.php#L845.

Modifications to this portion of code were made to handle comments on columns differently in doctrine/dbal 2.5, but it used to work in 2.4.3.



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Reverted to priority Major





[DBAL-1069] datetimetz type needs to be a commented one by default Created: 10/Dec/14  Updated: 10/Dec/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

By default, the AbstractPlatform creates datetimetz fields as datetime field for platforms not defining a specific creation for fields with timezones.
This can be an acceptable fallback if you know that your application always send the value as UTC even when the database can accept any timezone as input thanks to the datetimetz type (database not supporting timezone would still have consistent data if you always send the same timezone).
However it creates an issue for the SchemaTool: the field will obviously be reported as datetime when inspecting the DB, not as datetimetz (since it does not have a datetimetz). So for platforms not supporting datetimetz natively, the special comment should be used to avoid useless updates.
The special Doctrine command should however not be used for platforms supporting the type natively (PostgreSQL, SQLServer2008, Oracle and SqlAnywhere12).

I have an idea about a fix, so I may send a PR for this in the following days.






[DBAL-1065] sqlite: foreign keys Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

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

Type: Bug Priority: Major
Reporter: Miloslav Nenadál Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-866 Foreign Key Constraints does not work... Resolved

 Description   

It seems that operations (like listing) are not supported with foreign keys on sqlite.



 Comments   
Comment by Miloslav Nenadál [ 09/Dec/14 ]

the issue you linked is marked as resolved, but this really doesn't work:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SqlitePlatform.php#L695

because of the line above, when I run:

$connection = $container->get('doctrine.dbal.default_connection');
$schemaManager = $connection->getSchemaManager();
$tables = $schemaManager->listTables();

$foreignKeys = [];
foreach ($tables as $table) {
    $foreignKeys[$table->getName()] = $table->getForeignKeys();
}
var_dump($foreignKeys);

then I would see no foreign keys.

Comment by Marco Pivetta [ 09/Dec/14 ]

The linked issue is resolved as "invalid" because the foreign key support for sqlite was removed due to compatibility problems across sqlite versions.

Closing again.





[DBAL-866] Foreign Key Constraints does not work with Doctrine/Symfony and SQLite Created: 12/Apr/14  Updated: 09/Dec/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Christian S. Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None
Environment:

PHP 5.5.9, SQLite3 module version 0.7-dev, SQLite Library 3.8.3.1


Issue Links:
Duplicate
is duplicated by DBAL-1065 sqlite: foreign keys Resolved

 Description   

I have posted a question on stackoverflow already to get help on this issue, but nobody could give me a sufficient answer. See here.

#370 says that support for foreign keys support for SQLite has been implemented. But in my case it does not work. I have defined two entities:

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Category:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    oneToMany:
        ministries:
            targetEntity: Ministry
            cascade: [persist]
            mappedBy: category

And

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Ministry:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    manyToOne:
        category:
            targetEntity: Category
            inversedBy: ministries
            joinColumn:
                name: category_id
                nullable: false
                onDelete: CASCADE

But when I delete a category, the ministry entities do not get deleted, although the constraint should cascade. What am I missing?

Do I have to configure anything to get that working or is it a bug?



 Comments   
Comment by Marco Pivetta [ 22/Apr/14 ]

While some FK functionalities are supported by the DBAL, I reverted the feature in https://github.com/doctrine/dbal/commit/7282289fee625a24c26c1fccc0474e8ca583470f since it was too clunky, so the ORM doesn't recognize the platform as a platform that supports FKs.





[DBAL-1067] mysql: selecting db issue Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

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

Type: Bug Priority: Major
Reporter: Miloslav Nenadál Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1057 Connection is not lazy anymore when g... Open

 Description   

When I drop database and create it inside a program, I get error below in case I try to manipulate with db somehow (create table e.g.):

[PDOException]
SQLSTATE[3D000]: Invalid catalog name: 1046 No database selected

This not happens with sqlite3 or postgres - it happens with mysql only.






[DBAL-1066] [GH-738] Define composer test script Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: