[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 17/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




[DBAL-1080] [GH-748] minor phpdoc fixes in the remaining files Created: 16/Dec/14  Updated: 16/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


 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






[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 16/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


 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






[DBAL-1078] [GH-746] minor phpdoc fixes in the platform files Created: 16/Dec/14  Updated: 16/Dec/14  Resolved: 16/Dec/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cs, docblock


 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-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-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 16/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


 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.






[DBAL-1075] [GH-744] Removed non-phpdoc @internal tags Created: 15/Dec/14  Updated: 16/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
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-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 14/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


 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






[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 13/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved 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





[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-1071] [GH-740] Add 2.5 status to README Created: 11/Dec/14  Updated: 11/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.5.1
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-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-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-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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

The composer test script is an easy and convenient way to define your unit
testing scripts. It makes testing your library as easy as just running
`composer test`.

For more information about the `scripts` field check out [the manual](https://getcomposer.org/doc/articles/scripts.md) and [this blog post](http://maxgfeller.com/blog/2014/07/22/composer-test/).



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

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

Comment by Doctrine Bot [ 09/Dec/14 ]

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





[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-1064] Duplicate Encoding of column comments in MySQL Created: 06/Dec/14  Updated: 08/Dec/14  Resolved: 08/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: flack Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

I'm not sure if this was done on purpose or not, but I didn't find anything in UPGRADE.md, so I thought I'd file it to be sure:

When I set a column comment that looks like this: "set('auth')", DBAL 2.4 would generate the following SQL:

"CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set('auth')')"

2.5 OTOH create this:

"CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set(''auth'')')"

(the quotes around auth are not double quotes, but two single quotes, in case the font makes it impossible to see).

It is a minor change that I only noticed because one of my unit tests went red, but just by looking at it, the duplicate single quotes seem like an error. Let me know if this is something that should be fixed in DBAL or if I should simpy adjust my test to expect a different result



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

flack It's automatically escaping string literal delimiters now because using string literal delimiters inside a literal string requires escaping otherwise resulting in invalid SQL.

SQL query:
CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set('auth')')

MySQL said:
#1064 - 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 'auth')')' at line 1

SQL query:
CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set(''auth'')')

MySQL returned an empty result set (i.e. zero rows). (Query took 0.0147 seconds.)

You have to change your test suite.





[DBAL-1063] Exceptions from SchemaTool when running with DBAL 2.5.0 Created: 06/Dec/14  Updated: 15/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: flack Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 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





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

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: index
Environment:

any



 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





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

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4
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
relates to DBAL-1058 It seems that MSSQL syntax was changed Open
relates to DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Open

 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





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

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4, 2.5
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
relates to DBAL-1058 It seems that MSSQL syntax was changed Open
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Open

 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





[DBAL-1059] [GH-735] Bump version 2.6.0-DEV Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Task Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: release, version


 Description   

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

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

Message:

/cc @Ocramius @beberlei



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

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DBAL-1058] It seems that MSSQL syntax was changed Created: 05/Dec/14  Updated: 05/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: man4red Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, sqlserver

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

 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.





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

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: 4
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-1067 mysql: selecting db issue Resolved

 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.





[DBAL-1056] [GH-734] Sign release tags in ant build script Created: 04/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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 deeky666:

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

Message:

/cc @beberlei






[DBAL-1055] doctrine:schema:update SchemaException Created: 04/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Minor
Reporter: Danilo Henrique Fonseca Menezes Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: dbal, schematool


 Description   

I'm trying to run doctrine:schema:update

and a have been thrown this exception

[Doctrine\DBAL\Schema\SchemaException]
The table with name 'name.dbo' already exists.

There are at least two entities with the following mapping structure for the Table name:

/**
 * NotaLancamento
 *
 * @Table(name="name.dbo.notalancamento")
 * @Entity
 */
class NotaLancamento

I'm using MSSQL and the database_name parameter for the connection is a has a different name (for example, name2). In my project I need to access data on the database 'name' and 'name2' at the same time, and they both have the schema dbo, I've been trying to solve this problem for a while. I searched on stackoverflow but got no answers.

Any ideas about what should I do?



 Comments   
Comment by Danilo Henrique Fonseca Menezes [ 04/Dec/14 ]

Going up on the exception stack trace I found out that the
/Doctrine/DBAL/Schema/AbstractAsset.php in its _setName method introduces the problem:

protected function _setName($name)
    {
        if ($this->isIdentifierQuoted($name)) {
            $this->_quoted = true;
            $name = $this->trimQuotes($name);
        }
        if (strpos($name, ".") !== false) {
            $parts = explode(".", $name);
            $this->_namespace = $parts[0];
            $name = $parts[1];
        }
        $this->_name = $name;
    }

It assumes that the namespace+name of the table should have only one dot.

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

Danilo Henrique Fonseca Menezes DBAL always assumes that you operate on one database at the time. The Schema class refers to exactly one database. So you cannot map entities for multiple databases with the same entity manager / connection. This is currently not supported.

See also here: http://stackoverflow.com/questions/15389692/cross-database-joins-with-doctrine-in-php

We might reconsider supporting this in 3.x but we cannot add support for this in 2.x as it would have to many implications on all dependent projects. So closing this for now.

Comment by Danilo Henrique Fonseca Menezes [ 08/Dec/14 ]

Steve Müller, thank you for your information, I had already read the stackoverflow article you mentioned and I was trying to overcome the problem.

Anyway, thank you so much and I hope to see this feature on doctrine 3.

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

You're welcome. We might add more schema object layers in 3.0 to make things like this work. Basically what I want to have in 3.0 is the possibility to retrieve the complete schema objects that exist on a single physical database instance which can be queried with one connection and abstract that into different schema layers (table -> schema -> catalog -> cluster — according to the SQL-92 standard definition). But 3.0 is not planned yet so it will take awhile until this might be possible





[DBAL-1054] Expose native database handler from Connection Created: 03/Dec/14  Updated: 03/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Davide Romanini Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

DBAL drivers totally hide the wrapped native connection handler. Sometimes it is useful having a way to access it, eg: integrating old non-dbal code sharing the same connection, or to access specific funcionalities not available through the driver.
With oci8 for example I'd want to use oci_set_client_info/oci_set_module_name/oci_set_action on postConnect for better dba auditing and analysis. In current implementation the only way is to use reflection and access the protected $dbh instance variable, that's very fragile.
I propose to add a Connection::getNativeConnection() or similar name for this purpose and trivially implement it on the various drivers. BC compatibility could be an issue here, but eventually it could be factored in a more specific interface.



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

Davide Romanini which Connection are you refering to? The DBAL Connection class provides a getWrappedConnection() method which returns the underlying driver connection object.
If you refer to driver connections in the first place I doubt we will expose the internal connection ressource to avoid possible weird side effects. We had similar discussion several times now. If you need advanced access to driver specific functionality on the connection, please don't use DBAL. DABL is about abstraction accross different drivers and database vendors. It is not intended for advanced driver specific usage.

Comment by Davide Romanini [ 03/Dec/14 ]

getWrapperConnection() returns the DBAL specific connection (OCI8Connection in my use case). That is not a real "native" connection since it is a mere wrapper around the oci8 php module. In particular it doesn't allow to access some specific functions such as:

  • oci_set_action / oci_set_module_name / oci_set_client_info
  • oci_set_prefetch
  • ... other useful functions
    In my case I'm creating a listener that uses the first functions on the list to useful contextual values (eg: symfony controller/action names) to allow fine tuning and monitoring at the dba level. Obviously this is implemented as a cross-cutting concern with a listener without even touching the main application code. So your advise to not using DBAL for such a purpose seems impractical at best.
    Probably a cleaner solution could be to fully encapsulate all the oci8 functions in the OCI8Connection wrapper, creating a real "native" connection. But this is an hard effort, so my approach is more pragmatic.
    I really don't see the whole point of avoiding to "expose the internal connection ressource to avoid possible weird side effects". As a developer I should in any case know what I'm doing and especially when gradually migrating old oci8-based code sharing the same connection is the best approach in my experience. As a side note, improper use of a Connection::getNativeConnection() is just as harmful at least as improper use of EntityManager::getConnection().




[DBAL-1053] quotes in column comment are not escaped for PostreSQL Created: 01/Dec/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

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

Type: Bug Priority: Minor
Reporter: Johan Desmyter Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Debian 7, Symfony 2.3, PostgreSQL 9.1



 Description   

On an entity with a column which as a comment containing a quote, the schema update command doesn't work.

Example entity :

Vendor\Entity\Bob:
type: entity
table: bob
id:
id:
type: integer
generator:

{ strategy: AUTO }

fields:
friend:
type: string
options:
comment: bob's car

The following exception appear :

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'COMMENT ON COLUMN bob.friend IS 'bob's car':
SQLSTATE[42601]: Syntax error: 7 ERREUR: erreur de syntaxe sur ou près de « s car »
LINE 1: ...OLUMN bob.friend IS 'bob's car'

We can see that quot in comment is not escaped.



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

Already fixed in master branch as of https://github.com/doctrine/dbal/commit/439f67437083cf95c1fa5e56ab1614d7113895fb

See also: https://github.com/doctrine/dbal/pull/657





[DBAL-1052] [GH-731] Update AbstractSchemaManager.php Created: 30/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: filter, filtering, schema, schemadiff


 Description   

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

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

Message:

There is a optional filter included to list only tables/sequences with a specific prefix.



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

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





[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-1050] [GH-729] Support for database URLs Created: 26/Nov/14  Updated: 05/Dec/14

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: drivermanager, dsn, uri


 Description   

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

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

Message:

With a bunch of tests.

Of note:

1. in the case of information present in both URL and "normal" parameters, I'm currently giving priority to the information from the URL; IMO this makes more sense than vice versa (base info would be defined in params, and each developer or environment has a URL that may or may not override that base info, such as charset)
1. the syntax for SQLite is `sqlite:///relativepath.db` or `sqlite://ignoredhost/relativepath.db` for relative, and `sqlite:////tmp/absolutepath.db` or `sqlite://ignoredhost//tmp/absolutepath.db` for absolute paths to the database file (I went back and forth on this, but this way is easier and more consistent; https://github.com/kennethreitz/dj-database-url does the same)
1. extra query params are simply "copied" into `$params` verbatim; makes sense IMO especially considering point number 1



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

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





[DBAL-1049] [GH-728] Ignore pseudo-system objects in table list Created: 25/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

These objects are created by turning on replication and they have column types (sysname, xml) that are not supported by Doctrine.

According to Microsoft's support, these are "'pseudo-system' object[s]" that appear in the User Table type instead of the System Table type.

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/135ec547-2214-4da3-bd42-5c458759e144/sysobjectscategory

This issue is very similar to http://www.doctrine-project.org/jira/browse/DBAL-114 so I handled it in the same section of the code as the fix for that issue.



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

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

Comment by Doctrine Bot [ 02/Dec/14 ]

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

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

Fixed as of https://github.com/doctrine/dbal/commit/ea3715a100f20741d8a2088896f94c09dfeea920





[DBAL-1048] Function based index Created: 20/Nov/14  Updated: 20/Nov/14

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.





[DBAL-1047] doctrine:schema:update ignores index names set on Entity via Annotation Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/14

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

Type: Bug Priority: Minor
Reporter: webDEVILopers Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: schematool
Environment:

"php": ">=5.3.3",
"symfony/symfony": "2.5.*",
"doctrine/orm": "~2.4",
"doctrine/doctrine-bundle": "~1.2"


Issue Links:
Duplicate
duplicates DDC-2989 ORM should allow custom index names f... Open

 Description   

I am naming my indexes via annotations in my entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="delivery_notes", indexes={
 *  @ORM\Index(name="location_idx", columns={"location_id"}),
 *  @ORM\Index(name="user_idx", columns={"user_id"}),
 *  @ORM\Index(name="compartment_idx", columns={"compartment_id"})
 * })
 */
class DeliveryNote

When running doctrine:schema:update the names are ignored (at least when they don't exist yet):

CREATE INDEX IDX_1110401E64D218E ON delivery_notes (location_id);
CREATE INDEX IDX_1110401EA76ED395 ON delivery_notes (user_id);
CREATE INDEX IDX_1110401E6136A935 ON delivery_notes (compartment_id);

Is this an expected behaviour?



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

Duplicate of DDC-2989





[DBAL-1046] Broken link Created: 12/Nov/14  Updated: 02/Dec/14

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

Type: Task Priority: Minor
Reporter: ted bohus Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On the website, the link to download Doctrine DBAL 2.3.5 doesn't work...

http://www.doctrine-project.org/downloads/DoctrineDBAL-2.3.5-full.tar.gz

Thanks



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

ted bohus for now please use this link: https://github.com/doctrine/dbal/archive/v2.3.5.zip
We are having a look into the issue.





[DBAL-1045] [GH-727] Disallow empty delete criteria on the connection Created: 11/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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: Steve Müller
Resolution: Fixed 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/727

Message:

See #722

Ping @JeroenDeDauw @asm89



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Steve Müller [ 11/Nov/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/e35ce0486a1d161e739bed38fde27b7cc921f5f0





[DBAL-1044] [GH-726] MasterSlaveConnection::close() should reset connections array Created: 10/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: close, connection, master-slave


 Description   

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

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

Message:

When calling MasterSlaveConnection::close() the connections array should be restored to the default value.
Otherwise a subsequent call to the connect method will fire a PHP Notice because of undefined index in MasterSlaveConnection.php on line 165.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-1043] [GH-725] Exclude tables with table_type of VIEW Created: 10/Nov/14  Updated: 24/Nov/14  Resolved: 24/Nov/14

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

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


 Description   

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

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

Message:

This excludes views registered by PostGIS 2.x like geography_columns, geometry_columns, raster_columns and raster_overviews.

The table_name != 'geometry_columns' is kept for PostGIS 1.5 compatibility. The type changed to VIEW in PostGIS 2.0.

Failing tests: https://travis-ci.org/jsor/dbal/builds/40528525 (See #724)



 Comments   
Comment by Doctrine Bot [ 24/Nov/14 ]

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

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

Fixed as of https://github.com/doctrine/dbal/commit/40fd004725b4aa902aea170cd15152b06a6faba0

Comment by Doctrine Bot [ 24/Nov/14 ]

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





[DBAL-1042] [GH-724] Enable PostGIS extension for PostgreSQL tests Created: 10/Nov/14  Updated: 10/Nov/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


 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





[DBAL-1041] DBAL exception when detecting unknown database types is too vague Created: 09/Nov/14  Updated: 20/Nov/14  Resolved: 10/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Tom Vogt Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

OS X 10.9



 Description   

Using Symfony, updating a schema with

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

gives me this error after I updated Doctrine today:

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

The exception message verbosity is insufficient.



 Comments   
Comment by Marco Pivetta [ 10/Nov/14 ]

Reverted to minor

Comment by Marco Pivetta [ 10/Nov/14 ]

The confusion here comes from your database type, which is indeed "name" in your case.

See https://github.com/doctrine/dbal/blob/a2e87c57a9843f07e8e6d6e57fe0fff965c0f4ac/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L423 for reference.

Also, please take few moments more before opening an issue next time.
We are all doing what we can in our free time here, and raging doesn't help anyone.

Comment by Tom Vogt [ 10/Nov/14 ]

Sorry for the wording, I didn't intend to rage or insult anyone, I'm just very direct when I report a problem.

I'm not sure your assessment is correct. I do NOT have any database type called "name". I have a few fields with a name "name", but none where the TYPE is set to "name" (which would, obviously, be an invalid type).

for example, I have definitions like this:
<field name="name" type="string"/>

But nowhere in the code (verified by global search) is the TYPE ever set to "name".

Comment by Tom Vogt [ 10/Nov/14 ]

I was half-wrong there. I don't have any entity definitions with that type, but since I use PostGIS, there are a few views that use "name" as a column type.

using the undocumented schema_filter fixes it. Still, if this error would provide the table name, it would be a massive help. To find the problem, I had to put debug code into vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php

Comment by Marco Pivetta [ 11/Nov/14 ]

What can eventually be done is catching and re-throwing a more specialized exception in the location where it may occur. If you feel the need for it, then please open a pull request directly.

Comment by Jon West [ 20/Nov/14 ]

For those who are coming across this specific error and are using PostGIS, add this to your config in appropriate place.

doctrine:
dbal:
schema_filter: ^spatial_ref_sys





[DBAL-1040] [GH-722] Fix behaviour of Connection::delete when an empty array of criteria is provided Created: 07/Nov/14  Updated: 08/Nov/14  Resolved: 08/Nov/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 08/Nov/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DBAL-1039] [GH-721] Add @return type hint Created: 07/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: New Feature Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DBAL-1038] [GH-720] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: JSON, dbal

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





[DBAL-1037] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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: Terje Bråten Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: JSON, dbal

Issue Links:
Duplicate
duplicates DBAL-1038 [GH-720] Type json_array is not consi... Open

 Description   

Fields of type json_array are created as "TEXT NOT NULL".
If you then 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.

Either the field creation in the database must be changed to allow nulls, or the test must be changed to also test for the empty string.



 Comments   
Comment by Terje Bråten [ 07/Nov/14 ]

I created this ticket first, then a new one was automatically created when I submitted the pull request.

Please delete this ticket.

Comment by Marco Pivetta [ 07/Nov/14 ]

Terje Bråten marking it as duplicate is enough





[DBAL-1036] [GH-719] Added TraceLogger to get backtrace for executed queries Created: 05/Nov/14  Updated: 05/Nov/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


 Description   

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

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

Message:

Added a TraceLogger that returns a backtrace for the executed query.
The backtrace returns the last 10 frames, and it also formats the frames for easy reading






[DBAL-1035] [GH-718] implement method for retrying database queries/transactions Created: 05/Nov/14  Updated: 05/Nov/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


 Description   

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

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

Message:

It is best practice to implement retry logic for transactions that are aborted because of deadlocks or timeouts. This makes such method available inside the DBAL and also adds detection for errors where retrying makes sense in the different database drivers.

Deadlocks and timeouts are caused by lock contention and you often can design your application to reduce the likeliness that such an error occurs. But it's impossible to guarantee that such error conditions will never occur. This is why implementing retrying logic for such errors is actually a must when you have to ensure the application does not fail in edge cases or high load.
Some references where something similar has already been implemented:

I chose the name `retryable` because it is consistent with `transactional`. I think the implementation is quite straight forward and fits very well with the DBAL design.






[DBAL-1034] [GH-717] Fix tear down foreign key constraint violation exception tests Created: 05/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: tests, travis

Issue Links:
Dependency
is required for DBAL-1024 [GH-704] [DBAL-1024] Add more foreign... Resolved

 Description   

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

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

Message:

Fixes failing tests introduced in #704.



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

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1033] [GH-716] Do not TRIM() parentheses around partial indexe conditions Created: 05/Nov/14  Updated: 05/Nov/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


 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))"}

``






[DBAL-1032] [GH-715] Fix return type of Connection::project Created: 04/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: connection


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 04/Nov/14 ]

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

Comment by Doctrine Bot [ 04/Nov/14 ]

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





[DBAL-1031] Oracle driver using portability does not use SQL logger Created: 03/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Bret R. Zaun Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

We are using the Oracle driver with some portability settings.
When trying to add a SQL logger to that connection no queries are being logged.
Having a quick look that the code I could not a place where the logger would be called in that scenario.

Am I missing something or has this just been left out ?

To give some more details here is the code we use to connect:

        $connectionParams = array(
                'dbname' => ...,
                'user' => ...,
                'password' => ...,
                'port' => ...,
                'driver' => 'oci8,
                'wrapperClass' => 'Doctrine\DBAL\Portability\Connection',
                'portability' => \Doctrine\DBAL\Portability\Connection::PORTABILITY_ALL,
                'fetch_case' => \PDO::CASE_LOWER
        );
        $configuration = new Doctrine\DBAL\Configuration();
        $logger = new Doctrine\DBAL\Logging\DebugStack();
        $configuration->setSQLLogger($logger);
        $this->conn = Doctrine\DBAL\DriverManager::getConnection($connectionParams, $configuration);


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

SQL Logging happens at connection level, therefore the issue is not related with the oracle setup itself. Please try verifying if there is any bug by using the EchoSQLLogger: https://github.com/doctrine/dbal/blob/6458b0bd6e62817e961a9611959a67b5f8622b59/lib/Doctrine/DBAL/Logging/EchoSQLLogger.php





[DBAL-1030] [GH-713] Prevent result cache key collisions when sharing cache across different connections Created: 01/Nov/14  Updated: 10/Nov/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


 Description   

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

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

Message:

There's an issue when using the default cache key generation for the result cache and using the same cache system across different connections as the generated key will be the same regardless of the connection used.

We can solve this just by using the connection params in the key generation. This issue is quite similar to the one fixed in 1075(https://github.com/doctrine/doctrine2/pull/1075).



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DBAL-1029] [GH-712] Backporting a fix to allow connection without dbname Created: 31/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
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





[DBAL-1028] [GH-709] [DBAL-1028] Fix fetching NULL values via fetchColumn() Created: 27/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: fetchcolumn, pdostatement, prepared-statements


 Description   

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

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

Message:

`PDO` drivers return `null` when retrieving a SQL `NULL` value from a column via `Statement::fetchColumn()`.
However all native driver implementations except `mysqli` return `false` which according to the interface should only be returned if no more rows are available or an error occurred. So currently it is not possible to retrieve a SQL `NULL` value via `Statement::fetchColumn()` with those drivers.
This PR fixes this. Additionally if a non-existing column index is requested from the resultset, `PDO` also returns `null` whereas those mentioned native drivers return `false`. This is also fixed.



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

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1027] [GH-708] fix quoted sequence name Created: 27/Oct/14  Updated: 08/Nov/14  Resolved: 27/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: 2.5
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-831 [GH-540] unit test to create constrai... Resolved

 Description   

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

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

Message:

@deeky666 we lost some fixes during the past days

https://github.com/deeky666/dbal/pull/1/files
https://github.com/deeky666/dbal/pull/2/files

This pull request is intending to bring back these fixes - THX



 Comments   
Comment by Doctrine Bot [ 27/Oct/14 ]

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

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

Fixed as of https://github.com/doctrine/dbal/commit/a67db17b3d5bf373ba7a827db52dd0c7066cb08a

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DBAL-1026] [GH-707] Dbal 831 Created: 27/Oct/14  Updated: 27/Oct/14  Resolved: 27/Oct/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: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DBAL-1025] [GH-705] [DBAL-1025] Allow connecting without database name for sqlanywhere driver Created: 26/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

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


 Description   

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

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

Message:

It should be possible to connect without a `dbname` connection parameter on capable platforms so that operations like `CREATE DATABASE` can be performed.
This PR removes the constraint for `sqlanywhere` driver and adds a functional test for capable platforms.



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

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1024] [GH-704] [DBAL-1024] Add more foreign key constraint violation error codes Created: 26/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, pdoexception

Issue Links:
Dependency
depends on DBAL-1034 [GH-717] Fix tear down foreign key co... Resolved

 Description   

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

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

Message:

Driver exception conversion was missing some error codes for foreign key constraint violations. Currently only foreign key constraint violations for `DELETE` statements are tested. Foreign key constraint violations can also occur for `INSERT`, `UPDATE` and `TRUNCATE` write operations where some platforms provide dedicated error codes for.



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

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





[DBAL-1023] inconsistent line-ending Created: 24/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Improvement Priority: Trivial
Reporter: Dmitry Khlebnikov Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: coding-standards


 Description   

There are currently two files in the Git repository with DOS line endings. This is inconsistent with the rest of DBAL files in the repository and breaks Git when the DBAL repository is attached as a subtree to a project.

The files with DOS line endings are:

dbal/docs/design/AZURE_FEDERATIONS.md
dbal/tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL421Test.php



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

Patch provided in: https://github.com/doctrine/dbal/pull/706





[DBAL-1022] [GH-703] [DBAL-1022] Wrap PDOException in PDOConnection::exec() Created: 23/Oct/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

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


 Description   

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

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

Message:

Seems we forgot to wrap `\PDOException` in `PDOConnection::exec()` therefore calls like `PDOConnection::exec('DROP TABLE foo')` are not properly converted to `TableNotFoundException` accordingly. (or similar).



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-1021] [GH-702] [DBAL 930] Only introspect accessible schema objects in PostgreSQL Created: 23/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

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

Issue Links:
Reference
is referenced by DBAL-930 [GH-626] Update PostgreSqlPlatform.php Resolved

 Description   

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

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

Message:

Supersedes #626.

  • Rebased with master.
  • Adopted logic for `getListNamespacesSQL()` and `getListViewsSQL()`.

If anyone has an idea of how to test this, please let me know. Otherwise I would be fine without tests... :S



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

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





[DBAL-1020] Postgres and using Schema tool throws cardinality errors Created: 22/Oct/14  Updated: 23/Oct/14

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

Type: Bug Priority: Critical
Reporter: Dominic Watson Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ddl, postgresql

Attachments: PNG File 6ZeW_jJFUbOCx5uGJ2feANtAsZOr72zhDL4szJ6p5VE.png     File pg_catalog_pg_class.csv    

 Description   

Postgres: 9.3.5.0 (Postgres App for OSX) w/ PostGIS extensions
doctrine/common: 2.4.x-dev ae92d076442e27b6910dd86a1292a8867cf5cfe4
doctrine/dbal: dev-master 1c9c24a7e2295b71249ae2a719ce38861fccd551
creof/doctrine2-spatial: https://github.com/intellix/doctrine2-spatial 4023ca8fbe703043012c31d6df26b9bc7b0a972d

It seems every now and again when I come to use the schema-tool I'm getting exceptions which can only be fixed by dropping the database and recreating from scratch.

The following SQL looks to be generated here: \Doctrine\DBAL\Platforms\AbstractPlatform::getListTableForeignKeysSQL

SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef
                  FROM pg_catalog.pg_constraint r
                  WHERE r.conrelid =
                  (
                      SELECT c.oid
                      FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n
                      WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"',user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace
                  )
                  AND r.contype = 'f'

The full stack trace is as follows:

 ---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
  Dropping database schema...
      ./bin/doctrine-module orm:schema-tool:drop --force --verbose
---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
Dropping database schema...


                                                                                                                                                                                                       
  [Doctrine\DBAL\Exception\DriverException]                                                                                                                                                            
  An exception occurred while executing 'SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef                                                              
                    FROM pg_catalog.pg_constraint r                                                                                                                                                    
                    WHERE r.conrelid =                                                                                                                                                                 
                    (                                                                                                                                                                                  
                        SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace                                                                                              
                    )                                                                                                                                                                                  
                    AND r.contype = 'f'':                                                                                                                                                              
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression                                                                                     
                                                                                                                                                                                                       


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php:82
 Doctrine\DBAL\Driver\AbstractPostgreSQLDriver->convertException() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
 Doctrine\DBAL\DBALException::driverExceptionDuringQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:833
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [Doctrine\DBAL\Driver\PDOException]                                                                               
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:94
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [PDOException]                                                                                                    
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 PDO->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4


orm:schema-tool:drop [--dump-sql] [-f|--force] [--full-database]


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

What are the contents of pg_catalog.pg_class ?

Comment by Dominic Watson [ 22/Oct/14 ]

Uploaded CSV of that table

Comment by Dominic Watson [ 22/Oct/14 ]

After running the subquery as suggested in IRC:

  SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace  

oid
-------
40152
39687

Comment by Marco Pivetta [ 22/Oct/14 ]

Can you run the query:

SELECT
    c.*
FROM
   pg_catalog.pg_class c, pg_catalog.pg_namespace n
WHERE
    n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast')
    AND c.relname = 'state'
    AND n.nspname = ANY(string_to_array((
        select replace(replace(setting,'"$user"', user), ' ', '')
        from pg_catalog.pg_settings
        where name = 'search_path'
    ),','))
    AND n.oid = c.relnamespace
Comment by Dominic Watson [ 22/Oct/14 ]
  relname varchar,
  relnamespace oid,
  reltype oid,
  reloftype oid,
  relowner oid,
  relam oid,
  relfilenode oid,
  reltablespace oid,
  relpages int,
  reltuples real,
  relallvisible int,
  reltoastrelid oid,
  reltoastidxid oid,
  relhasindex bool,
  relisshared bool,
  relpersistence char(1),
  relkind char(1),
  relnatts smallint,
  relchecks smallint,
  relhasoids bool,
  relhaspkey bool,
  relhasrules bool,
  relhastriggers bool,
  relhassubclass bool,
  relispopulated bool,
  relfrozenxid xid,
  relminmxid xid,
  relacl _aclitem,
  reloptions _text

state,2200,40154,0,10,0,40152,0,0,0,0,0,0,true,false,p,r,2,0,false,true,false,true,false,true,6694,1,NULL,NULL
state,39587,39689,0,10,0,39687,0,0,0,0,39694,0,true,false,p,r,15,3,false,true,false,false,false,true,6629,1,NULL,NULL
Comment by Dominic Watson [ 22/Oct/14 ]

My ZF2 onBootstrap as well, in case it changes anything:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
<?php
namespace Flatscanner;

use Doctrine\ORM\Mapping\UnderscoreNamingStrategy;
use ZF\Apigility\Provider\ApigilityProviderInterface;
use Zend\Uri\UriFactory;
use Doctrine\DBAL\Types\Type;

class Module implements ApigilityProviderInterface
{
    public function getConfig()
    {
        return include __DIR__ . '/../../config/module.config.php';
    }

    public function onBootstrap($e)
    {
        Type::addType('geometry', 'CrEOF\Spatial\DBAL\Types\GeometryType');
        Type::addType('point', 'CrEOF\Spatial\DBAL\Types\Geometry\PointType');
        UriFactory::registerScheme('chrome-extension', 'Zend\Uri\Uri');

        // Set naming strategy
        $em = $e->getTarget()->getServiceManager()->get('doctrine.entitymanager.orm_default');
        $em->getConnection()->getDatabasePlatform()->registerDoctrineTypeMapping("_text", "text"); // assuming it is a text LOB
        $em->getConfiguration()->setNamingStrategy(new UnderscoreNamingStrategy(CASE_LOWER));
    }

    public function getAutoloaderConfig()
    {
        return array(
            'ZF\Apigility\Autoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__,
                ),
            ),
        );
    }
}
Comment by Steve Müller [ 23/Oct/14 ]

Most probably also affects 2.4 as the codebase has not changed at the critical places. Possibly 2.3 is also affected by this. Could need a check.





[DBAL-1019] [GH-701] [DBAL-944] Fix table column alteration on DB2 Created: 22/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

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

Issue Links:
Reference
relates to DBAL-945 [GH-633] Db2altercolumnsyntaxbug Resolved
is referenced by DBAL-944 db2 alter column produces invalid sql... Resolved

 Description   

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

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

Message:

Replacement for #633 as it was messed up, incomplete, untested and wrong.



 Comments   
Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1017] Altering a foreign key column is not done properly for MySQL Created: 21/Oct/14  Updated: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, schematool


 Description   

Altering a foreign key column column (for instance to make it not-nullable) or the index of a foreign key does not work on MySQL (to be exact, it does not work on some MySQL setups, but I haven't found the config setting impacting it yet). Making it work requires dropping the foreign key before altering the column/index and readding it after



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

Christophe Coevoet DBAL-732 related?





[DBAL-1016] [GH-700] [DBAL-1016] Fix explicitly quoted table identifiers in ALTER TABLE statements Created: 20/Oct/14  Updated: 26/Oct/14  Resolved: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, quoting, schemadiff, schematool

Issue Links:
Reference
is referenced by DBAL-753 Evaluate owncloud patch for Oracle qu... Resolved

 Description   

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

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

Message:

Another improvement to the neverending quotation issues.
This patch fixes explicitly quoted table identifiers in `ALTER TABLE` statements.
Additionally some minor fixes had to be applied such as misc fixing of foreign key constraint statements order in the sequence of statements necessary to alter a table.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1015] [GH-699] Adds support for setting the charset in SQLSrv Created: 20/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: charset, dsn, encoding, mssql, sqlserver


 Description   

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

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

Message:

As seen here => http://technet.microsoft.com/en-us/library/cc626307(v=sql.105).aspx



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1014] [GH-698] [DBAL-1014] Support HHVM mysqli driver Created: 20/Oct/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

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

Type: Improvement Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hhvm, mysqli


 Description   

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

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

Message:

Adds support for HHVM's mysqli driver implementation.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DBAL-1013] [GH-696] [DBAL-1013] Fix table diff's new name if it is not set Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, schematool


 Description   

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

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

Message:

The `TableDiff` should not wrap `TableDiff::$newName` into an `Identifier` if it is not set.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1012] [GH-695] [Documentation] Add missing quotes at the end of literal strings Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 17/Oct/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, documentation


 Description   

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

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



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

Fixed as of https://github.com/doctrine/dbal/commit/d400586168bfc19b8fe84d7cf9f432b54ce21306

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1011] [GH-694] [DBAL-1011] Fix column comments containing string literal chars on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, escaping, schematool


 Description   

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

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

Message:

When trying to create or update a column with a comment containing the string literal quote character `'`, SQL generation is invalid and fails on execution. This patch now quotes the particular comment to come around this issue.






[DBAL-1010] [GH-693] [DBAL-1010] Fix renaming column with default value on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, schematool

Issue Links:
Reference
relates to DBAL-830 [GH-539] unit test added for altering... Resolved

 Description   

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

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

Message:

Doctrine throws a fatal error on renaming a column with a default value set because of nested `Identifier` objects as old column name.
This issue was introduced by https://github.com/doctrine/dbal/pull/672.



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-1009] [GH-692] [DBAL-1009] Fix column comment lifecycle Created: 16/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: comments, ddl, schematool


 Description   

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

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

Message:

The lifecycle of a column comment is not correct.
The comparator would not detect added comments. Also platforms did not handle the licecycle consistently.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1008] [GH-691] Add test case for #688 Created: 16/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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

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

Issue Links:
Dependency
is required for DBAL-997 [GH-685] Update MasterSlaveConnection... Resolved
is required for DBAL-1003 [GH-688] Fixed closing a connection Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-1007] [GH-681] Fixed expanding positional parameters which do not start from 0 Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: sql-parser





[DBAL-1006] [GH-690] Backport [DBAL-717] Fix bug in MasterSlaveConnection with keepSlave option and switch back after transaction. Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

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

Issue Links:
Dependency
depends on DBAL-335 Is MasterSlaveConnection implemented ... Resolved
depends on DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-1005] Timezones of DateTime instances are ignored when persisting dates Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

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

Type: Bug Priority: Major
Reporter: Brent Shaffer Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

When a DateTime instance, e.g. "2011-02-16 00:00:00 America/New_York" is written into the DB, the timezone is ignored and only "2011-02-16" is persisted. When fetching the date, it is written into a DateTime with the server's timezone, resulting in for example "2011-02-16 00:00:00 Europe/Berlin" which is not correct!

To fix this issue, Doctrine should convert dates to the server's timezone (if their own timezone differs) before persisting them or before executing queries containing DateTime instances.



 Comments   
Comment by Brent Shaffer [ 15/Oct/14 ]

I would like to reopen this issue - Doctrine is expecting the incoming DateTime objects to have the system's default_timezone. If they do NOT use the default timezone (let's say they, instead use UTC), then the date is saved in the format of the default timezone anyway, and upon hydration, the UNIX timestamp changes.

I don't see how this could ever be considered expected behavior. Doctrine is essentially modifying the timestamp being persisted.

Doctrine should set the timezone of the DateTime object prior to persistence using the date_default_timezone_get() method. Either that, or the persisted string should contain the timezone identifier of the initial DateTIme object.

Comment by Marco Pivetta [ 15/Oct/14 ]

See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/working-with-datetime.html

The current DateTime type completely ignores timezones and we will keep it like that for now.

Comment by Brent Shaffer [ 15/Oct/14 ]

@Marco thank you for your quick reply. Can you help me understand why the decision was made to expect the timezone to be the default instead of just setting it to be that way before persistence? It seems like all these woes could have been easily avoided...

Comment by Marco Pivetta [ 15/Oct/14 ]

Brent Shaffer it was indeed a mistake to not use stricter rules on DateTime instances, but due to the amount of code depending on this behavior right now, we cannot change the Doctrine\DBAL\Types\DateTimeType anymore.

Instead, we may consider introducing a new UTC-based datetime-type for 3.x.

A change is not going to be applied on existing logic.





[DBAL-1004] [GH-689] [DBAL-1004] Fix generating COMMENT ON COLUMN statements for quoted identifiers Created: 15/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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

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


 Description   

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

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

Message:

Fixes SQL generation for `COMMENT ON COLUMN` statements on all platforms.
See also: https://github.com/doctrine/dbal/pull/687#issuecomment-59203122



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-1003] [GH-688] Fixed closing a connection Created: 14/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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

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

Issue Links:
Dependency
depends on DBAL-1008 [GH-691] Add test case for #688 Resolved
is required for DBAL-997 [GH-685] Update MasterSlaveConnection... Resolved

 Description   

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

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

Message:

The inner connection should be unreferenced, but the property should not be removed from the object

Refs https://github.com/doctrine/dbal/pull/685



 Comments   
Comment by Doctrine Bot [ 14/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-1002] [GH-687] [DBAL-1001] Fix NULL / NOT NULL clause for column alterations in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
is required for DBAL-1001 NULL / NOT NULL clause always appende... Resolved

 Description   

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

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

Message:

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a `NULL` / `NOT NULL` clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.
See also: https://github.com/doctrine/dbal/pull/676#issuecomment-57643477



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1001] NULL / NOT NULL clause always appended to column alteration declaration in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
depends on DBAL-1002 [GH-687] [DBAL-1001] Fix NULL / NOT N... Resolved
Reference
relates to DBAL-472 Oracle schema modification - incorrec... Resolved

 Description   

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a NULL / NOT NULL clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.



 Comments   
Comment by Marco Pivetta [ 19/Oct/14 ]

Solved in DBAL-1002





[DBAL-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 26/Oct/14

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

Type: Bug Priority: Critical
Reporter: Marcus Malka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, mysql

Attachments: PNG File Screen Shot 2014-10-14 at 10.53.44.png    

 Description   

When trying to create a database via Symfony (tested 2.3, 2.4, 2.5) console using Doctrine, if returns

[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[42000] [1049] Unknown database 'livedb_ci_tco_dev'

This effectively prevents re-creating the database.

I traced the error, it seems database existence is either not checked or not functioning, and it tries to connect to the DB, resulting in an exception. In older versions the trace seemed like it checked if DB exists, and didn't try to connect.

I tested some different commit versions to assess where the bug was introduced - here is my brief list of working/non-working versions.

812dd9d (v.2.5.0-BETA3) fail
61eb1ee fail
3176f51 fail
da43b76 works
ce3a56e works
594e326 works
ba9aa63 (v.2.5.0-BETA2) works

So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51



 Comments   
Comment by Marco Pivetta [ 14/Oct/14 ]

Marcus Malka are you sure that you are running the correct command? If the DB is not there, I would expect an exception.

Comment by Christophe Coevoet [ 14/Oct/14 ]

Marco Pivetta This command is precisely about creating the database when it does not exist yet. I think this failure is related to the guessing of the platform version in DBAL 2.5, which will require connecting to the DB early.

Comment by Marco Pivetta [ 14/Oct/14 ]

Christophe Coevoet the screenshot shows the `drop` command being used

Comment by Marcus Malka [ 14/Oct/14 ]

I tested with multiple commands, mainly drop and create were most common.

The difference is in the error that gets produced with the different commits applied - other one gives the "The database is not there" kind of error you would expect. The other version gives an "can't do the operation because I can't connect to the database" even when you try to create it, and gives a similar "can't drop the database because I can't connect to the database" kind of error, which still says it tries to do something weird. My screenshot could've been taken from the create-command too, the error was identical.

I should have a breaking composer.json file in my version control on another machine. I'll try to add that later to facilitate debugging.

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

Christophe Coevoet you are right, that DBAL now connects early if you request the database platform but that should not be an issue as you may not specify a non-existing database name when connecting to creating a new database, anyways. And as far as I can see the CreateDatabaseDoctrineCommand even explicitly unsets the database name in the connection params here: https://github.com/doctrine/DoctrineBundle/blob/master/Command/CreateDatabaseDoctrineCommand.php#L71-L80 for a "temporary" connection.
Dropping a database still should require the database to be existent so connecting to it before dropping should be fine or am I missing something here?

Comment by Marcus Malka [ 15/Oct/14 ]

@Steve Muller - is it tries to create the connection and creates an error also when the database is not supposed to be there, for ex. in create action. Effectively breaking createDatabase command.

When I traced the code, it seemed to go in to the platform version checking, and seemed like it just didn't realize early enough that the DB isn't there (that was my guess - I don't know doctrine internals well enough to say if that's how it's planned to work or not).

Comment by Benjamin Eberlei [ 26/Oct/14 ]

This is an issue in DoctrineBundle that only appears in combination with DBAL 2.5.

The problem is Symfony apparently connects to the database in "Container::get" of the connection already. That has to be fixed.





[DBAL-999] Get a Sql Server error on Order By - Symfony2 Created: 08/Oct/14  Updated: 19/Oct/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.





[DBAL-998] [GH-686] Add test for explicit positional parameter keys in SQLParserUtils Created: 08/Oct/14  Updated: 08/Oct/14  Resolved: 08/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

To prove PR #681 is working correctly.






[DBAL-997] [GH-685] Update MasterSlaveConnection.php Created: 06/Oct/14  Updated: 22/Oct/14  Resolved: 14/Oct/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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-1003 [GH-688] Fixed closing a connection Resolved
depends on DBAL-1008 [GH-691] Add test case for #688 Resolved

 Description   

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

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

Message:

If you use close method just before connect method, $this->_conn is unset and we have got an error php.



 Comments   
Comment by Doctrine Bot [ 06/Oct/14 ]

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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

Comment by Marco Pivetta [ 14/Oct/14 ]

Incorrect fix, as it fixes a symptom rather than the issue itself





[DBAL-996] [GH-684] Changed the composer constraint to allow Common 2.5 Created: 05/Oct/14  Updated: 07/Oct/14  Resolved: 07/Oct/14

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

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


 Description   

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

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

Message:

I also changed the PHPUnit dev constraint to allow usign supported versions (the latest is 4.2, not 4.0)






[DBAL-995] [GH-683] Fix phpDoc comments to return $this instead of fully qualified class name Created: 03/Oct/14  Updated: 03/Oct/14  Resolved: 03/Oct/14

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

Type: Improvement Priority: Trivial
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 Max101:

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

Message:

Scenario:
Im extending the QueryBuilder class, adding new methods and returning $this.

In the latest PhpStorm(and probably other editors) the higlighter sees an error because the inherited methods return an exact class name of the parent instead of $this.






[DBAL-994] [GH-682] [WIP] [DBAL-218] Add bulk insert query Created: 30/Sep/14  Updated: 30/Sep/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


 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-993] TimeType should reset date fields to UNIX epoch Created: 26/Sep/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

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

Type: Bug Priority: Major
Reporter: Pavel Horal Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: datetime, type

Issue Links:
Reference
relates to DDC-179 Time part of Date fields is initializ... Resolved

 Description   

What is the issue

This issue is similar to DDC-179 . The problem is that when working with time field types that the value is parsed with the current date. Special '!' format prefix or '|' format suffix should be used to reset date fields to UNIX epoch.

Why is it issue

Resetting fields to a well defined value will allow correct time-based \DateTime comparisons, which is not possible in the current implementation (at least not without hacks).

We came across this behaviour when working with Symfony2 forms. Symfony2 form components are using '|' (pipe) format suffix when parsing time fields. This generates incorrect change-sets on data layer.



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

I don't get the issue here. It was already patched in DDC-179, no? See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DateType.php#L65
If I am missing something here, can you please give more details or provide an example of your use case?

Comment by Pavel Horal [ 26/Sep/14 ]

I am talking about https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/TimeType.php#L65 . So it is pretty much the same as DDC-179, but just a different temporal type.

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

I guess I understand. So you would expect the date part to be resetted to UNIX epoch, right? Like:

$time = '08:59:44';

$timeType->convertToPHPValue($time, $platform); // returns a \DateTime object of '1970-01-01 08:59:44'
Comment by Pavel Horal [ 26/Sep/14 ]

Exactly.

The current behavior feels incorrect, because if you have two entries in the DB both set to 06:00:00 and you will parse one at 2014-09-26T23:59:59.999 and the second one at 2014-09-27T00:00:00.000 they will be parsed to a different timestamps.
Also as I have mentioned the current behaviour don't play nice with Symfony2's date and time form fields (https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/DataTransformer/DateTimeToArrayTransformer.php#L176), which always resets unparsed fields to UNIX epoch.
And at last the current behavior is a bit inconsistent with date handling introduced in DDC-179.

Comment by Marco Pivetta [ 19/Oct/14 ]

Needs test case + patch: Pavel Horal can you provide a PR for this issue?

Comment by Pavel Horal [ 19/Oct/14 ]

Created https://github.com/doctrine/dbal/pull/697 .

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DBAL-992] [GH-680] Enabled placeholders for "in" method in ExpressionBuilder Created: 18/Sep/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: in, parameters, querybuilder


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-991] [GH-679] [DBAL-774] Fix QueryBuilder parsing order of joins Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4
Fix Version/s: 2.5
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-774 DBAL parses joins in wrong order Resolved
relates to DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved

 Description   

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

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

Message:

This is a fix for DBAL-774(http://www.doctrine-project.org/jira/browse/DBAL-774) and is the followup for PR #548.



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-990] [GH-678] Clean up unused uses Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Getting rid of unused `use` statements



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-989] Tag new version for 2.3.x Created: 15/Sep/14  Updated: 17/Sep/14  Resolved: 15/Sep/14

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

Type: Task Priority: Major
Reporter: Jeroen Thora Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

Hi,

Would it be possible to release a new version of doctrine 2.3.x? I stumbled into this issue DBAL-522 and there was a fix (and merged in 2.3 branch). Don't know if you still support the 2.3 version, but there were some fixes done which are not included in a tag/release. See 2.3.4...2.3 diff

In the 2.4 branch (releases) this is fixed but because of issue DBAL-774 i'm unable to upgrade to 2.4

Thanks



 Comments   
Comment by Marco Pivetta [ 15/Sep/14 ]

A new 2.3.x should be viable: can you backport the patch into a PR targeted at the 2.3 branch?

Comment by Jeroen Thora [ 15/Sep/14 ]

The fix for this issue was already backported into the 2.3 branch, but it wasn't included in any release so far. But I just saw that deeky released a new 2.3.5 version, so as far as i can see now, this should be fixed. But will confirm tomorrow!

Comment by Steve Müller [ 15/Sep/14 ]

Jeroen Thora yes, released 2.3.5 today. Blog post will follow later.

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-988] [GH-677] avoid recursive quoteIdentifier call Created: 11/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

each $part does not contain ".", so quoteSingleIdentifier may be called directly thus avoiding recursive strpos checks.



 Comments   
Comment by Steve Müller [ 12/Sep/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/0d99f152573c2da1a4884cc90a9fdfc038f47f7b





[DBAL-987] [GH-675] [DBAL-959] Allow to get bound parameter types from query builder Created: 11/Sep/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

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

Issue Links:
Dependency
is required for DBAL-959 [GH-648] Allow to get bound parameter... Resolved

 Description   

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

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

Message:

Replaces https://github.com/doctrine/dbal/pull/648.

Added tests.



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-986] [GH-674] Fix typos Created: 03/Sep/14  Updated: 03/Sep/14  Resolved: 03/Sep/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 03/Sep/14 ]

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

Comment by Doctrine Bot [ 03/Sep/14 ]

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





[DBAL-985] [GH-673] Fix DocBlock type hint Created: 02/Sep/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

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

Type: Documentation Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

`$changedColumns` is actually an array of `Doctrine\DBAL\Schema\ColumnDiff` instances.



 Comments   
Comment by Doctrine Bot [ 02/Sep/14 ]

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

Comment by Doctrine Bot [ 02/Sep/14 ]

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





[DBAL-984] [GH-671] Fix quoted integers as default value. Created: 28/Aug/14  Updated: 19/Oct/14  Resolved: 29/Aug/14

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

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


 Description   

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

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

Message:

The comparison names for the bigint and smallint types in the sql declaration for default values are misspelled and the values are returned quoted unlike the integer type that is returned unquoted.



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

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

Comment by Steve Müller [ 29/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/60a19586699e9e6ab734c810103ae4294f2ab77f

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-983] [GH-670] Handle default values for boolean, datetime, and datetimetz columns in PostgreSQL Created: 27/Aug/14  Updated: 28/Aug/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


 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





[DBAL-982] [GH-669] Correct schema generation for altering PostgreSQL sequences Created: 25/Aug/14  Updated: 19/Oct/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


 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





[DBAL-981] [GH-668] Fix: Travis-CI configuration Created: 24/Aug/14  Updated: 24/Aug/14  Resolved: 24/Aug/14

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

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


 Description   

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

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

Message:

Reference: http://till.klampaeckel.de/blog/archives/204-Whats-wrong-with-composer-and-your-.travis.yml.html



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

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





[DBAL-980] [GH-667] Add tests for select all behaviour when not using a table alias Created: 21/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Steve Müller [ 22/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/14f730fb2e02df2c1daf8df09057b6771d5c226a





[DBAL-979] [GH-666] [DBAL-924] Fix SQLite integer type primary autoincrement columns Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 21/Aug/14

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

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

Issue Links:
Duplicate
duplicates DBAL-923 [GH-618] sqlite does not support bigint Resolved
duplicates DBAL-924 [GH-619] fix all sqlite integer types Resolved

 Description   

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

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

Message:

This is a followup PR for https://github.com/doctrine/dbal/pull/618 and https://github.com/doctrine/dbal/pull/619.
It provides a compromise between PK autoincrement column declaration and differenciation of different integer types.
Each integer type column that is declared as an autoincrement column will fallback to `INTEGER` SQL declaration while keeping the possibility to create non-autoincrement columns for each integer type.
There should also be no comparator issues left with this PR generating useless SQL diffs.



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

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Steve Müller [ 21/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/b6cd3238b4a71f755b9e3a80f39d5551910b73a6

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-978] [GH-665] convenience method for FULL OUTER JOINs in QueryBuilder Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 11/Sep/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 davidkalosi:

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

Message:

was working on a project today where I needed a full outer join and found out that the method was missing in the QueryBuilder.
It's a minor change and I have also included a test case.

david



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-977] [GH-664] [DBAL-669] Make schema visit namespaces Created: 21/Aug/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

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

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

Issue Links:
Reference
relates to DBAL-669 Postgresql platform schema creation f... Resolved

 Description   

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

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

Message:

This PR is a followup to https://github.com/doctrine/dbal/pull/444 and fixes schema not visiting namespaces.
Because of this issue the ORM test suite is [currently failing](https://travis-ci.org/doctrine/doctrine2/jobs/32975659). The schema tool is not creating the namespaces before actually creating the namespace prefixed tables, therefore one test case is failing in ORM.
With this PR now the `CreateSchemaSqlCollector` is also generating the appropriate namespace creation SQL.



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

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

Comment by Steve Müller [ 21/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/fce77af2c3c6f8446b868c729cd15257c2c9bd81





[DBAL-976] [GH-663] [DDC-2310] [2.4] Fix evaluation of NOLOCK table hint on SQL Server Created: 20/Aug/14  Updated: 11/Nov/14  Resolved: 20/Aug/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2310 Recent changes to DBAL SQL Server pla... Resolved
relates to DBAL-783 [GH-508] [DDC-2310] Fix evaluation of... Resolved

 Description   

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

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

Message:

Backport to 2.4 of https://github.com/doctrine/dbal/pull/508 required for https://github.com/doctrine/doctrine2/pull/925.



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

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

Comment by Steve Müller [ 20/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/f15c4823b1bc5fceacc199765709cb67001445b2

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-975] [GH-662] Allow current timestamp default to be specified for DateTimeTz type. Created: 17/Aug/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

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: Marco Pivetta
Resolution: Fixed 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/662

Message:

Currently there is no way to specify a current timestamp as a default when using the `DateTimeTz` type, as it will always be quoted by the system. For example, the generated schema would have:

`DEFAULT 'NOW()'`

Instead of the correct:

`DEFAULT NOW()`

This simple fix allows `DateTimeTz` to behave just as `DateTime` in this regard.



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

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

Comment by Doctrine Bot [ 19/Aug/14 ]

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





[DBAL-974] Escape Table Columns on Insert Created: 16/Aug/14  Updated: 18/Aug/14  Resolved: 18/Aug/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: Minor
Reporter: Andreas Möller Assignee: Steve Müller
Resolution: Can't Fix Votes: 0
Labels: None

Attachments: File ace_mag.sql    

 Description   

I use Doctrine to handle the following MySQL table (See attachment).
As you can see, the MySQL table has a column "by".

If you want to insert values by using the insert function of the Connection Class, an error appears:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1064 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 'by, bz, bt, lat, lon) VALUES ('2014-08-16 16:35:00', '0', '-2.3', '0.7', '-0.8',' at line 1' in ..

I used:

$entry = array(
  'date' => '2010-01-01 12:10:10',
  'status' => '0',
  'bx' => '0',
  'by' => '0',
  'bz' => '0',
  'bt' => '0',
  'lat' => '0',
  'lon' => '0',
);

$connection->insert($table, $entry);

The reason is, that Doctrine does not escape the "by" value. MySQL parses "by" as a statement.

False:

INSERT INTO solar.ace_mag (date, status, bx, by, bz, bt, lat, lon) VALUES ...

Correct:

INSERT INTO `solar`.`ace_mag` (`date`, `status`, `bx`, `by`, `bz`, `bt`, `lat`, `lon`) VALUES ...

I wrote the following helper function to escape my insert values-keys:

public static function prepareInsertValues(array $insertValues)
    {
        foreach ($insertValues as $key => $val) {
            $insertValues['`' . $key . '`'] = $val;
            unset($insertValues[$key]);
        }

        return $insertValues;
    }

PS: Maybe other function are effected (e.g. UPDATE,...)



 Comments   
Comment by Steve Müller [ 18/Aug/14 ]

Andreas Möller this is a known issue we cannot fix in a reliable way. The Connection API is not intended to consume user input data because of possible SQL injection vulnerabilities. Escaping identifiers is not as easy as it might seem at the first glance and your provided helper function does only escape "clean" identifiers which do not contain the escape character or even SQL injection code. For further information please have a look here:

http://www.doctrine-project.org/2014/02/21/security_in_doctrine.html





[DBAL-973] [GH-661] Added field specific options for converting data between PHP and DB Created: 15/Aug/14  Updated: 15/Aug/14  Resolved: 15/Aug/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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Added option parameter so field specific data can be passed when converting data for types. This is needed in cases like enum types or more generic types where you want field specific options for conversion.

This would give developers more freedom in creating custom domain-specific types.

Our (simplified) use-case is:
```php
class EnumType extends Type
{
const ENUM = 'enum';

public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)

{ return 'Enum'; }

public function convertToPHPValue($value, AbstractPlatform $platform, array $options = [])

{ return (null === $value) ? null : new $options['class']((int) $value); }

public function convertToDatabaseValue($value, AbstractPlatform $platform, array $options = [])

{ return $value; }

public function getName()

{ return self::ENUM; }

}
```
This way you can define a generic Enum and configure the matching type of the enum in the field itself. The end goal is to make use of this change in the ORM as follows:
```php
class Entity
{
/**

  • @ORM\Column(
  • name = "bar",
  • type = "enum",
  • type_options = { * "class" = "\Foo\Bar\FooBarEnum" * }
  • )
  • @var FooBarEnum
    */
    private $foo;
    }
    ```


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

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

Comment by Doctrine Bot [ 15/Aug/14 ]

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





[DBAL-972] [GH-660] Fix rst list Created: 12/Aug/14  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The current version is not displayed correctly at
http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/portability.html



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

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

Comment by Steve Müller [ 13/Aug/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/83f92c3f28e927917ddcb7cf214ce99c0b72004b





[DBAL-971] [GH-659] Improve QueryBuilder docs Created: 12/Aug/14  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

  • Remove aliases from examples where they make no sense
  • Fixed copy paste error


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

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

Comment by Doctrine Bot [ 12/Aug/14 ]

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





[DBAL-970] Implement partial indexes for missing platforms Created: 12/Aug/14  Updated: 12/Aug/14

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

Type: Improvement Priority: Major
Reporter: Steve Müller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

As a follow-up to DBAL-900 there are some platforms left that support partial indexes too and need the implementation for that feature.
Currently partial indexes are only implemented for PostgreSQL.
Additionally there should be a functional test covering creation and introspection of partial indexes if possible.






[DBAL-969] [GH-658] DBAL-968 Created: 11/Aug/14  Updated: 11/Aug/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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

The recent change to SQLServerPlatform.php (https://github.com/doctrine/dbal/commit/17dad30dc9acd91a5cda0da2c5ce2c40d522f766) broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.






[DBAL-968] SQL Server modifyLimitQuery broken Created: 11/Aug/14  Updated: 11/Aug/14

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: William Schaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator, sqlserver
Environment:

SQL Server



 Description   

The recent change to SQLServerPlatform.php @jaylinski:improved sqlserver 'doModifyLimitQuery' select-from pattern broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.



 Comments   
Comment by Marco Pivetta [ 11/Aug/14 ]

I'm gonna cry. Thank you, MSSQL, you make our lives so much "easier"





[DBAL-967] [GH-656] allow nested functions as second parameter to DATE_* functions Created: 06/Aug/14  Updated: 10/Aug/14  Resolved: 10/Aug/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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Using sqlite as backend you can't pass nested function for the second parameter of DATE_* functions since it is transformed to a string. I've fixed that concatenating the string expression passed to sqlite DATE and DATETIME function using the getConcatExpression method - does this seem correct?

The DATE_* functions work fine with nested second parameter in mysql.

I've added assertions similar to other platforms for the date functions.



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

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





[DBAL-966] [GH-655] json_array columns should return null for null values Created: 06/Aug/14  Updated: 06/Aug/14  Resolved: 06/Aug/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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-446 Type json_array can't be null Reopened

 Description   

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

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

Message:

I guess this is a BC-break, but it fixes DBAL-446(http://www.doctrine-project.org/jira/browse/DBAL-446).



 Comments   
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 Marco Pivetta [ 06/Aug/14 ]

Fix cannot land in 2.x

Comment by Doctrine Bot [ 06/Aug/14 ]

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





[DBAL-965] [GH-654] doModifyLimitQuery() was missing an outer "ORDER BY doctrine_rownum" Created: 06/Aug/14  Updated: 23/Oct/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


 Description   

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

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

Message:

Refer to:
http://www.doctrine-project.org/jira/browse/DBAL-940



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-964] [GH-653] Update docs to include warning when using object type with PostgreSQL Created: 05/Aug/14  Updated: 05/Aug/14  Resolved: 05/Aug/14

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

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

Issue Links:
Reference
is referenced by DDC-3241 object type fails to save serialized ... Open

 Description   

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

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

Message:

Follow up to: http://www.doctrine-project.org/jira/browse/DDC-3241



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

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





[DBAL-963] [GH-652] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/14

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

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


 Description   

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

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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





[DBAL-962] [GH-651] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/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: 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 accdavid:

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Marco Pivetta [ 04/Aug/14 ]

PR was opened with wrong merge origin/target





[DBAL-961] [GH-650] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/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: 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 accdavid:

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Marco Pivetta [ 04/Aug/14 ]

wrong target/origin branches





[DBAL-960] [GH-649] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/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: 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 accdavid:

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Marco Pivetta [ 04/Aug/14 ]

Wrong merge origin/target branches





[DBAL-959] [GH-648] Allow to get bound parameter types from query builder. Created: 04/Aug/14  Updated: 11/Sep/14  Resolved: 11/Sep/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: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-987 [GH-675] [DBAL-959] Allow to get boun... Resolved

 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-958] [GH-647] Update docs to relfect the changes to QueryBuilder::from made in #646 Created: 01/Aug/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 01/Aug/14 ]

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





[DBAL-957] [GH-646] Make the $alias parameter in the `from` method optional Created: 31/Jul/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

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

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


 Description   

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

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

Message:

The refactoring commits can be merged first using PR #645



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

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

Comment by Doctrine Bot [ 01/Aug/14 ]

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





[DBAL-956] [GH-645] Improvements to QueryBuilder Created: 31/Jul/14  Updated: 31/Jul/14  Resolved: 31/Jul/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: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments