[DBAL-551] [GH-340] Added driver map getter Created: 25/Jun/13  Updated: 24/Oct/14  Resolved: 10/Aug/13

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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

We can think of several situations where a read access to the supported drivers is required. I personnaly need it in the following use cases :

  • Validating a driver choice in a mutli-platform application installer
  • Generating migration classes for all the available platforms

This PR just adds a getter for that list. As it is a harmless and non-BC-break change, it would be great if it could be merged also into the 2.3 version.



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

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

Comment by Doctrine Bot [ 24/Oct/14 ]

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





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

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

Type: Improvement Priority: Trivial
Reporter: Dmitry Khlebnikov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 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






[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: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved 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






[DBAL-930] [GH-626] Update PostgreSqlPlatform.php Created: 29/Jun/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: ddl, postgresql, schema

Issue Links:
Reference
relates to DBAL-1021 [GH-702] [DBAL 930] Only introspect a... Open

 Description   

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

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

Message:

If the database have different schemes, with objects, that the actual logged in user has no rights, the existing statements will collect all objects (sequences and tables) and try to read them in later steps. This will throws exceptions. The reason for that is the fact, that both procedures getListSequencesList() and getListTablesSQL() will receive all known database objects from postgres catalogs. But the actual logged-in user, maby has no read permissions to object inside other scheme-owner. The additional parts inside both sql-statements will reduce the result to only objects that the user are able to see.



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

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





[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-940] ORDER BY with LIMIT in SQL Server does not work correctly Created: 17/Jul/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: M.K. Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, offset, orderBy, sqlsrv
Environment:

SQL Server


Issue Links:
Reference
relates to DBAL-927 [GH-622] improved sqlserver 'doModify... Resolved

 Description   

The function doModifyLimitQuery() in Doctrine\DBAL\Platforms\SQLServerPlatform does work correctly.

It removes the user generated ORDER BY (gets moved to OVER clause), but does not apply an ORDER BY on the row number created with ROW_NUMBER().

$orderBy = stristr($query, 'ORDER BY');

//Remove ORDER BY from $query (including nested parentheses in order by list).
$query = preg_replace('/\s+ORDER\s+BY\s+([^()]+|\((?:(?:(?>[^()]+)|(?R))*)\))+/i', '', $query);

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d';

The last format string should be:

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d ORDER BY doctrine_rownum';


 Comments   
Comment by Marco Pivetta [ 17/Jul/14 ]

Possible relation with DBAL-927

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

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





[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-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: 22/Oct/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: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved 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... Reopened

 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





[DBAL-945] [GH-633] Db2altercolumnsyntaxbug Created: 20/Jul/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
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: Incomplete Votes: 0
Labels: db2, ddl

Issue Links:
Reference
relates to DBAL-944 db2 alter column produces invalid sql... Reopened
is referenced by DBAL-1019 [GH-701] [DBAL-944] Fix table column ... Open

 Description   

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

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

Message:

fix for http://www.doctrine-project.org/jira/browse/DBAL-944



 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





[DBAL-944] db2 alter column produces invalid sql syntax Created: 20/Jul/14  Updated: 22/Oct/14

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

Type: Bug Priority: Major
Reporter: chris rehfeld Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: db2, ddl
Environment:

db2 v10.5 centos 6.5 64


Issue Links:
Reference
relates to DBAL-1019 [GH-701] [DBAL-944] Fix table column ... Open
is referenced by DBAL-945 [GH-633] Db2altercolumnsyntaxbug Resolved

 Description   

The "alter column" sql produced is always incorrect.

Example entity

Widget3.php
<?php
/**
 * @ORM\Entity
 **/
class Widget3
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="string", length=20) **/
    private $str;
}

orm:schema-tool:create produces:
CREATE TABLE Widget3 (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, str VARCHAR(20) NOT NULL, PRIMARY KEY(id));

If you then change the entity like so:

Widget3.php
    /** @ORM\Column(type="string", length=100) **/
    private $str;
}

If you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET3 ALTER STR str VARCHAR(100) NOT NULL;

which is invalid sql. It should be
ALTER TABLE WIDGET3 ALTER COLUMN STR SET DATA TYPE VARCHAR(100);

This renders the schema-tool inoperable in many scenarios, and causes a large portion of the db2 functional tests to fail.



 Comments   
Comment by chris rehfeld [ 20/Jul/14 ]

pull request https://github.com/doctrine/dbal/pull/633

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





[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-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-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-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-796] [GH-518] support to ibmi db2 - as400 Created: 22/Jan/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: as400, db2, ibmi


 Description   

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

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

Message:

support for ibmi db2 (as400)
some code in DB2Platform doesn't yet work on ibmi db2



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

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1016] [GH-700] [DBAL-1016] Fix explicitly quoted table identifiers in ALTER TABLE statements Created: 20/Oct/14  Updated: 21/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


 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-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-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-872] [GH-570] Add support for out cursor in OCI8 Created: 18/Apr/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: cursor, oracle


 Description   

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

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

Message:

I don't know if it is the best solution, but it's a beginning.



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Marco Pivetta [ 19/Oct/14 ]

See discussion on github for more details: can't implement a feature that is adapter-specific and has no abstraction layer on top.





[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-923] [GH-618] sqlite does not support bigint Created: 12/Jun/14  Updated: 19/Oct/14  Resolved: 23/Jun/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

Issue Links:
Duplicate
is duplicated by DBAL-979 [GH-666] [DBAL-924] Fix SQLite intege... Resolved

 Description   

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

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

Message:

BIGINT should be falling back to integer for SQLite



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

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

Comment by Steve Müller [ 23/Jun/14 ]

Reopened in: https://github.com/doctrine/dbal/pull/619

Comment by Doctrine Bot [ 04/Jul/14 ]

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

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 [ 19/Oct/14 ]

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





[DBAL-924] [GH-619] fix all sqlite integer types Created: 16/Jun/14  Updated: 19/Oct/14  Resolved: 21/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: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-979 [GH-666] [DBAL-924] Fix SQLite intege... Resolved

 Description   

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

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

Message:

The SQLite platform introduced integer types that are not supported. This PR addresses integer issues with SQLite



 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 [ 19/Oct/14 ]

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





[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-947] [GH-634] Transaction object definition Created: 21/Jul/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

Issue Links:
Reference
is referenced by DDC-2279 [GH-571] Update lib/Doctrine/ORM/Enti... Resolved

 Description   

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

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

Message:

To move forward with the Transaction Object, here is an alternative proposal to #571.

This keeps the same basic idea, but now `createTransaction()` returns a `TransactionDefinition` object, which is configurable, and has a `begin()` method that starts the underlying transaction and returns the `Transaction` object:

$tx = $em->createTransaction() // TransactionDefinition
->withIsolationLevel(Connection::TRANSACTION_SERIALIZABLE) // TransactionDefinition
->begin(); // Transaction

I think that this implementation checks all the boxes:

  • Clear separation between the Transaction and its Definition
  • Once the Transaction is created, its Definition is set and cannot be changed
  • No risk to forget to call `begin()`: if you do, you'll deal with a TransactionDefinition and just get a call to undefined method if you try to `commit()` it. Plus, your IDE will be able to warn you while coding.

And needless to say, we're still keeping 100% BC compatibility.

What do you think?






[DBAL-919] [GH-615] Add sanitization for IN() expressions Created: 05/Jun/14  Updated: 19/Oct/14  Resolved: 26/Jun/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: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

The current IN() expression is vulnerable to SQL injection and should be sanitized. It should be noted that the default is set to string because this works for all types including numeric values. However, this method can be slow for large lists. A recent test of 8,000 values too about .38 seconds. Numeric values only take about .015 seconds for the same data set.



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[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-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-609] [GH-373] HHVM compatibility: implement declared interfaces Created: 15/Sep/13  Updated: 19/Oct/14  Resolved: 13/Dec/13

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

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


 Description   

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

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

Message:

HHVM does not allow declaration of interface implementation without real implementation of methods which parameters differs from parent class.



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[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-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-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-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-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-831] [GH-540] unit test to create constraint on forced lowercase table in oracle Created: 04/Mar/14  Updated: 19/Oct/14  Resolved: 19/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: None


 Description   

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

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

Message:

This might be crazy - but this was working in the 2.3.x code basis.

On master as well as 2.4.2 following error is throws:
````
Exception : [Doctrine\DBAL\Exception\TableNotFoundException] An exception occurred while executing 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;':

ORA-00942: table or view does not exist
ORA-06512: at line 6

With queries:
6. SQL: 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;' Params:
5. SQL: 'CREATE TABLE "oc_storages" ("id" VARCHAR2(64) NOT NULL, "numeric_id" NUMBER(10) NOT NULL, PRIMARY KEY("id"))' Params:
4. SQL: 'DROP TABLE "oc_storages"' Params:
3. SQL: 'DROP TRIGGER "OC_STORAGES"_AI_PK' Params:
2. SQL: 'ALTER SESSION SET NLS_TIME_FORMAT = 'HH24:MI:SS' NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_TZ_FORMAT = 'YYYY-MM-DD HH24:MI:SS TZH:TZM' NLS_NUMERIC_CHARACTERS = '.,'' Params:

Trace:
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/DBALException.php:116
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Connection.php:988
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:971
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:429
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:569
/home/deepdiver/Development/ownCloud/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/OracleSchemaManagerTest.php:118

#0 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\Exception\TableNotFoundException))
#1 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest))
#3 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), '/::testConstrai...', Array, Array, false)
#6 /usr/share/php/PHPUnit/TextUI/Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 /tmp/ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 /tmp/ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9

{main}

````



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

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[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-830] [GH-539] unit test added for altering a column's default where the column name is... Created: 04/Mar/14  Updated: 16/Oct/14  Resolved: 10/Sep/14

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

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

Issue Links:
Reference
is referenced by DBAL-1010 [GH-693] [DBAL-1010] Fix renaming col... Resolved

 Description   

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

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

Message:

... a keyword - fails on mssql:

Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0':

SQLSTATE [42000, 3728]: [Microsoft][SQL Server Native Client 11.0][SQL Server]'DF_D3D4D2F1_4BF2EAC0' is not a constraint.
SQLSTATE [42000, 3727]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Could not drop constraint. See previous errors.

With queries:
5. SQL: 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0' Params: 
4. SQL: 'SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       (obj.name = 'column_keyword_test' AND scm.name = SCHEMA_NAME())' Params: 
3. SQL: 'ALTER TABLE column_keyword_test ADD CONSTRAINT DF_D3D4D2F1_ACF51D19 DEFAULT 23 FOR [select]' Params: 
2. SQL: 'CREATE TABLE column_keyword_test ([select] INT NOT NULL)' Params: 

Trace:
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Connection.php:988
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:971
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:612
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\SQLServerSchemaManager.php:232
C:\projects\doctrine\dbal\tests\Doctrine\Tests\DBAL\Functional\Schema\SchemaManagerFunctionalTestCase.php:619
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:976
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:831
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:776
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php:176
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:268
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:506

#0 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\DBALException))
#1 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest))
#3 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), false, Array, Array, false)
#6 C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9 {main}


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

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





[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-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-335] Is MasterSlaveConnection implemented correctly - seems to overwrite master connection on transaction methods? Created: 31/Aug/12  Updated: 16/Oct/14  Resolved: 17/Sep/12

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

Type: Bug Priority: Major
Reporter: Jonathan Ingram Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DBAL-1006 [GH-690] Backport [DBAL-717] Fix bug ... Resolved

 Description   

Forgive me to doubt, but I think there may be a bug in MasterSlaveConnection.

It's easier to understand what I'm saying by debugging and tracing the flow, but I'll illustrate it with gists.

First, here is a simple service method to create a user. It opens up a transaction, persists the user, commits and returns. On error, if there is an active transaction, rollback. Here is the gist:

https://gist.github.com/3547674

The "$conn->beginTransaction();" line is where we trace through (the remainder of the service method is now irrelevant). Looking into MasterSlaveConnection.php, we see the method tries to connect to the master connection (call this point ###):

https://gist.github.com/3547720

Now looking in the next gist, we see what happens when "$this->connect('master');" is called. At this point it's not that interesting, the internal "$this->_conn" property is set to "master".

https://gist.github.com/3547750

Now here lies the bug I believe. "parent::beginTransaction();" is called. When looking into this method, we see that another call is made to connect but this time without "master" as the argument (i.e. connect to slave). This call to connect is made before incrementing the transaction nesting level.

https://gist.github.com/3547808

Now, I won't do another gist for "MasterSlaveConnection::connect", but if you refer to the file at line 13 https://gist.github.com/3547750#file_master_slave_connection.php, you will see that it checks the transaction nesting level and if it is there, forces master. However, we don't increment the level until after the method returns, so the slave is used. Ultimately, this results in the internal "$this->_conn" property set to the "slave" connection which violates our original action at ### above where we said we want to connect to "master".

Am I missing something here? Here is a gist the is a basic attempt at fixing this one method. It simply copies the code from the parent method except does not connect twice. I believe the same would have to occur for all the other methods unless it can be fixed once at the "MasterSlaveConnection::connect" level.

https://gist.github.com/3547880

I've just fleshed out "beginTransaction", "commit" and "rollBack" in "MasterSlaveConnection" by basically copying and pasting the code from the parent class and for my failing use case, this fixes the issue. However, it did require updating "Connection" slightly so that I had access to some private variables.



 Comments   
Comment by Lars Strojny [ 31/Aug/12 ]

This looks indeed like a bug. From a first glimpse the fix would be to use master, if master is already connected.

Comment by Benjamin Eberlei [ 05/Sep/12 ]

This only happens when "keepSlave" = true, because then the master is not written into the slave property aswell:

   } else {
     $this->connections['slave'] = $this->_conn = $this->connectTo($connectionName);
   } 

Are you using keepSlave = true?

Comment by Jonathan Ingram [ 05/Sep/12 ]

Yes I am. Does that render this moot or still a bug?

Comment by Benjamin Eberlei [ 06/Sep/12 ]

Its still a bug, but it helps to know why this happens.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

Fixed in master and 2.3, can you test it?

Comment by Jonathan Ingram [ 19/Sep/12 ]

Thanks for doing this. I will test it shortly.

Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

not sure if you managed to test this but now test on mysql database fails with results below.
Probably some typo.

There was 1 error:

1) Doctrine\Tests\DBAL\Functional\MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster
Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

With queries:
2. SQL: 'CREATE TABLE master_slave_table (test_int INT NOT NULL, PRIMARY KEY(test_int)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

Trace:
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DbalFunctionalTestCase.php:73
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/DBALException.php:47
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92





[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-717] Cannot reconnect to slave in some cases of keepSlave Created: 21/Dec/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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

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

Issue Links:
Dependency
is required for DBAL-1006 [GH-690] Backport [DBAL-717] Fix bug ... Resolved
Duplicate
is duplicated by DBAL-527 [GH-323] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-531 [GH-325] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-519 MasterSlave connection does not keep ... Resolved

 Description   

See https://github.com/doctrine/dbal/pull/325 and https://github.com/doctrine/dbal/pull/326



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

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





[DBAL-527] [GH-323] Update MasterSlaveConnection.php Created: 22/May/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of ananda-agrawal:

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

Message:

check $this->keepSlave before enforcing master as slave



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

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

Comment by Benjamin Eberlei [ 21/Dec/13 ]

Duplicate of DBAL-717

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-531] [GH-325] Update MasterSlaveConnectionTest.php Created: 26/May/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of ananda-agrawal:

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

Message:

the test testKeepSlaveBeginTransactionStaysOnMaster does not begin a transaction, I have put a begin transaction, and now it fails,

the fix is here, if it makes sense
https://github.com/ananda-agrawal/dbal/commit/eb9262afb3955e4974d5a713b495a544b66a5cf7



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

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

Comment by Benjamin Eberlei [ 21/Dec/13 ]

Duplicate of DBAL-717

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-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 15/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: 0
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).





[DBAL-472] Oracle schema modification - incorrect SQL to change the nullable status of column Created: 26/Mar/13  Updated: 14/Oct/14  Resolved: 29/Dec/13

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

Type: Bug Priority: Major
Reporter: Andy Park Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

Centos 6 PHP 5.3.3 Oracle 11g


Issue Links:
Reference
is referenced by DBAL-1001 NULL / NOT NULL clause always appende... Resolved

 Description   

When updating the nullable status of a column the sql generated is

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) DEFAULT NULL)

This will set the default column value to null but does not modify the nullable status of the column. The correct sql would be

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) NULL)

The field definition changed from

metar:
type: string
length: 2000
nullable: false
column: METAR

to

metar:
type: string
length: 2000
nullable: true
column: METAR



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

Works for me strangely.

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

Patch supplied in PR: https://github.com/doctrine/dbal/pull/467

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[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-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-608] [GH-372] HHVM compatibility: func_get_args Created: 15/Sep/13  Updated: 22/Sep/14  Resolved: 15/Sep/13

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

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

Issue Links:
Reference
relates to DDC-2681 [GH-790] HHVM compatibility: func_get... Resolved
is referenced by DDC-3317 [GH-1142] func_get_args() call order ... Resolved

 Description   

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

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

Message:

All func_get_args() calls have been moved to the top of the methods because HHVM doesn't keep a copy of the original args for performance reasons.

See facebook/hiphop-php#1027 for details.



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

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

Comment by Guilherme Blanco [ 15/Sep/13 ]

Merged

Comment by Doctrine Bot [ 22/Sep/14 ]

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





[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/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: None
Security Level: All

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

Issue Links:
Reference
relates to DBAL-774 DBAL parses joins in wrong order Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

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

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

Message:

I had finaly some time to investigate the problem a bit more, and the problem is the way doctrine/dbal >= 2.4 handles the parsing of joins

The expected result is the way doctrine/dbal 2.3 handles the joins, which is not quite the way i expect that the query would be outputted but it is correct for execution.



 Comments   
Comment by Jeroen Thora [ 21/Mar/14 ]

Pullrequest related to DBAL-774

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-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: querybuilder

Issue Links:
Reference
is referenced by DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

I have a problem that doctrine dbal orders the joins in a wrong order if you use more complex join combinations (worked fine in DBAL 2.3)

Dbal Querybuilder:

        $qb->select('tbl_profile_additional_property.pkid AS pkid')
        ->from('tbl_profile_additional_property', 'tbl_profile_additional_property')
        ->leftjoin('tbl_profile_additional_property', 'tbl_rating_system', 'tbl_rating_system', 'tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid')
        ->leftjoin('tbl_rating_system', 'tbl_rating_system_translation', 'tbl_rating_system_translation', 'tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid')
        ->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')
        ->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')
        ->where('tbl_profile_additional_property.fk_function = :functionid')
        ->setParameter('functionid', $functionId)
        ->setParameter('languageid', $languageId);

Expected Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

Resulted Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

(The last 2 LEFT JOINS of the query are the problem)

The problem is with getSQLForJoins it loops over all the joins and foreach join it follows all the used joins aliases until the deepest point. Therefor it will parse this join first

->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')

Before it generates the sql for this line (this line is needed becaus the line above needs a join on tbl_score_level first)

->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')

The order the querybuilder in php is build (select, from, joins, etc) is the order it should be parsed as sql.

Ps. I have added 2.5 also as affectsversion because the code didn't change as far is i know



 Comments   
Comment by Chesley Brown [ 22/Jan/14 ]

Noticing this issue with v2.4 as well. However, I'm also noticing the leftJoins being ordered incorrectly on v2.3.3 as well... however the ordering between the two versions are not the same. They are both just ordered differently than the order that I actually call the leftJoin methods in.

Comment by Jeroen Thora [ 21/Mar/14 ]

I have added a failing test for this problem in doctrine/dbal#548

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 Marco Pivetta [ 17/Sep/14 ]

Resolved in DBAL-991 - won't be backported in 2.4 as 2.4 behavior could radically change otherwise.





[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-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-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-552] Colon (":") in field name treats like query parameter Created: 25/Jun/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

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

Type: Bug Priority: Major
Reporter: Daniel Bojdo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-624 Parameter in comments is parsed Open

 Description   

The colon sign (":") is permitted for columns' name but Doctrine treats them like parameters placeholder:

SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1

causes DBALException:

An exception occurred while executing 'SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1' with params ["2013-06-24 14:22:18"]: Value for :col_name not found in params array. Params array key should be "col_name"


 Comments   
Comment by Benjamin Eberlei [ 25/Jun/13 ]

does this work with plain PDO?

Comment by Daniel Bojdo [ 25/Jun/13 ]

Yes, it works perfectly fine with PDO. It also works properly with Doctrine\DBAL\Connection.
I suppose there's a bug somewhere in QueryBuilder.

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

Patch supplied in PR: https://github.com/doctrine/dbal/pull/477

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-766] PostgreSQL: Fix statement for getTableWhereClause method Created: 05/Jan/14  Updated: 15/Sep/14  Resolved: 05/Jan/14

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

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


 Description   

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






[DBAL-760] [GH-490] Don't return warnings as errors in sqlsrv driver Created: 03/Jan/14  Updated: 15/Sep/14  Resolved: 03/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.3, 2.3.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/490

Message:

The SQL Server platforms use `sp_rename` stored procedure for renaming schema objects like tables, indexes or columns. SQL Server raises a warning when invoking this stored procedure, although the result is as expected:

```php
Doctrine\DBAL\Driver\SQLSrv\SQLSrvException: SQLSTATE [01000, 15477]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Vorsicht: Wenn Sie Teile eines Objektnamens ��ndern, werden Skripts und gespeicherte Prozeduren m��glicherweise funktionsunf��hig.
```

This PR configures the sqlsrv driver not to handle warnings returned from the server as errors to prevent this. The PDO_SQLSRV driver silences warnings, too.



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

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





[DBAL-741] [GH-474] Fix foreign key columns order in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.5, 2.3.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/474

Message:

The order of columns in foreign key constraints is not synchronized by the Oracle platform.

*Failing test:*
```bash
Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest::testListForeignKeysComposite
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (

  • 0 => 'id'
  • 1 => 'foreign_key_test'
    + 0 => 'foreign_key_test'
    + 1 => 'id'
    )

/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/SchemaManagerFunctionalTestCase.php:672
```



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

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





[DBAL-742] [GH-475] Fix column default value introspection in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.2, 2.3.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/475

Message:

A bug in `OracleSchemaManager` cause a column's default value always to be null. Besides that default values are enclosed in single quotes when retrieved from database which is not evaluated by the schema manager, either.
This PR also fixes the default value tests in Oracle's functional test suite.



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

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





[DBAL-589] Doctrine\DBAL\Schema\Column::visit has an Invalid Type Hint Created: 27/Aug/13  Updated: 15/Sep/14  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.4
Fix Version/s: 2.3.5

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

$ php -v
PHP 5.4.15 (cli) (built: Aug 16 2013 15:38:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ uname -a
Darwin chrispmg.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



 Description   

Column::visit typehints against a class that doesn't exist (`Doctrine\DBAL\Schema\Visitor`).

https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L398

Looks like there's a `use` statement at the top of the file that imports the correct class: https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L23






[DBAL-613] [GH-377] Fixed logic error in Sharding component Created: 24/Sep/13  Updated: 15/Sep/14  Resolved: 26/Sep/13

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

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


 Description   

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

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

Message:

No need to choose shard by chooser, as is pass the identifiers shard.



 Comments   
Comment by Doctrine Bot [ 26/Sep/13 ]

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





[DBAL-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 15/Sep/14  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: 2.4, 2.3.5

Type: Bug Priority: Blocker
Reporter: lemeunier Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal
Environment:

Mac OSX 10.8.3, Mysql 5.5.28, PHP5.4



 Description   

Hello, i have got an error with doctrine 2.3.4 when i try to run the following code :

 
    $conn->executeQuery(
        'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
         array('foo' => 1, 'bar' => null)
     );

Error : Value for :bar not found in params array. Params array key should be "bar"

This code worked with doctrine 2.3.3.

I think the error comes from the function 'extractParam' in SQLParserUtils.php (DBAL)

line 215 : if (isset($paramsOrTypes[$paramName]))

The key exists even if the value is null.
So it should be:

  if (array_key_exists($paramName, $paramsOrTypes)) 

I am not enough confident to try a PR.
Thanks in advance!



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

I suggested a hotfix at https://github.com/doctrine/dbal/pull/322

Comment by lemeunier [ 21/May/13 ]

Thanks for the hotfix.





[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-816] [GH-529] fix for postres listTableNames Created: 18/Feb/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: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

fix for listTableNames to return unescaped table names



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

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[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-449] [GH-274] Support column charset/collation on capable platforms Created: 19/Feb/13  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: Benjamin Eberlei Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Basically the same feature wanted as in #245



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

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-647] MySqlPlatform's getCollationFieldDeclaration() looks like it has the wrong name Created: 01/Nov/13  Updated: 11/Sep/14  Resolved: 26/Nov/13

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

Type: Bug Priority: Major
Reporter: John Flatness Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

The MySqlPlatform has a method getCollationFieldDeclaration(). As far as I can tell, that method's not actually used for anything.

However, looking at the other Platforms and the AbstractPlatform, it looks like this method is what is elsewhere called getColumnCollationDeclarationSQL().

The AbstractPlatform calls getColumnCollationDeclarationSQL() when getting the SQL for a column with a "collation" set; for MySQL, this currently causes no effect since the default, blank implementation from the AbstractPlatform is being used.

It looks like the name of this method should be changed.



 Comments   
Comment by John Flatness [ 05/Nov/13 ]

The current name of the method looks like it dates back to the initial refactorings for Doctrine 2. No other methods there still use the "Field" terminology in the method name, and all the others that return snippets of SQL uniformly use "DeclarationSQL" instead of just "Declaration".

That combined with the different name for seemingly the same method in the AbstractPlatform and SQLServerPlatform makes it seem like this one just got left behind.

Comment by Steve Müller [ 25/Nov/13 ]

The reason for this diverge in implementation and terminology is that there still is an open PR that enables support for column collation declaration on capable platforms which is not yet merged:

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

and

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

Partial support for SQL Server has already been merged in:

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

This feature is nearly finished and about to be merged. AbstractPlatform::getCollationFieldDeclaration() will be deprecated then to ensure BC. Does that answer your question? =) If so, can this ticket be closed?

Comment by John Flatness [ 26/Nov/13 ]

I believe that does answer my question.

One little thing: when you say AbstractPlatform::getCollationFieldDeclaration() will be deprecated, you mean the one on MysqlPlatform, right? I believe there is no such method on the AbstractPlatform.

Comment by Steve Müller [ 26/Nov/13 ]

Yes it will be deprecated in MySQLPlatform. See the PR.
Can you tell me what is still unclear? Or what you'd expect of this ticket?

Comment by John Flatness [ 26/Nov/13 ]

Okay, then I think it was just a typo in your first comment.

PR #245 on Github seems like it covers this squarely, so I suppose this issue doesn't stand for much on its own.

Comment by Steve Müller [ 26/Nov/13 ]

You are right it was not supposed to be AbstractPlatform but MySQLPlatform

Comment by Doctrine Bot [ 11/Feb/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[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-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support Created: 25/Jan/13  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

Type: Improvement Priority: Minor
Reporter: amr Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Dependency
depends on DBAL-731 [GH-465] [DBAL-423] Optimize non-nati... Resolved

 Description   

I'm using MySQL with entities that have GUID ids. Therefore I'm using @ORM\Column(type="guid") for the ORM mapping. As MySQL does not have a native GUID data type, it gets mapped to type="string" with a default length of 255 -> VARCHAR(255). I don't really understand why we don't limit the length to 36, which is the fixed length for GUIDs. You could even think about using CHAR(36) for MySQL.

-> see Doctrine\DBAL\Platforms\AbstractPlatform -> getGuidTypeDeclarationSQL()



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

Patch PR: https://github.com/doctrine/dbal/pull/465

Comment by Michael Kühn [ 28/Feb/14 ]

With the latest support for the MyISAM-Engine merging this pull request would save some trouble.

Background/Steps to reproduce:
If you have 2 entities with guid/uuid as primary key, @ManyToMany/@JoinTable fails on MyISAM, because it would create a jointable with 2 VARCHAR(255) columns and would apply a combined primary key on these two columns. But MyISAM doesn't support keys longer than 1000 bytes so you can't create the jointable.

See: https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html

The maximum key length is 1000 bytes. This can also be changed by changing the source and recompiling. For the case of a key longer than 250 bytes, a larger key block size than the default of 1024 bytes is used.

In my opinion this isn't just a "minor" issue but a major because some people can't run on MySQL with InnoDB for some reason.

Comment by Marco Pivetta [ 28/Feb/14 ]

Michael Kühn MyISAM is niche support for the ORM - using a custom type is perfectly fine in such a case.

Comment by Michael Kühn [ 04/Mar/14 ]

Marco Pivetta I agree, but i don't see why we would assume a GUID/UUID - which is per definition 36 chars long - as a 255 char long string. It would save storage space (for platforms don't supporting a native uuid type) and circle around at least 1 barrier if using MyISAM.

By the way, the PR is missing something. While it works perfectly fine the first time, every orm:schema-tool:update would output the guid-columns every time if you don't specifiy "length=36" and "fixed=true" on every GUID-@Column. IMHO the GUID-Type should implicit this both attributes in this pull request so you don't get column updates that don't change anything.

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

Michael Kühn I get your point and thanks for pointing out the remaining issue. The problem is caused by the comparator which detects differences in the column definition because the length and fixed attribute are hardcoded in the platform which is beyond comparator's knowledge. Still I think this can be fixed easily but as long as Benjamin Eberlei is of the opinion that this change is a minor BC break, this PR won't make it into the master branch.

Comment by Doctrine Bot [ 10/Sep/14 ]

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

Comment by Marco Pivetta [ 10/Sep/14 ]

Resolved in DBAL-731





[DBAL-731] [GH-465] [DBAL-423] Optimize non-native GUID type declaration Created: 23/Dec/13  Updated: 10/Sep/14  Resolved: 10/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-423 Type GUID = VARCHAR(255) on platforms... Resolved

 Description   

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

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

Message:

Currently non-native GUID type is mapped to `VARCHAR(255)` which is not effective as GUID always has a fixed length of 36 characters. Therefore it should be mapped to `CHAR(36)` instead.



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

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





[DBAL-934] [GH-628] bug fix for db2 v10 new column def of syscat.columns.default Created: 05/Jul/14  Updated: 10/Sep/14  Resolved: 10/Sep/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 rehfeldchris:

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

Message:

It seems like ibm changed the column type of the column named "default" in syscat.columns in db2 luw v10. Probably in db2z too, but I haven't looked.

in v9.7 it was VARCHAR(254)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_9.7.0%2F2-10-7-17&lang=en

in 10.1 its CLOB(64k)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_10.1.0%2F2-9-8-18&lang=en

This causes an sql statement to fail. In
file: doctrine/dbal/lib/Doctrine/DBAL/Platforms/DB2Platform.php
method: getListTableColumnsSQL()

We make some sql like

SELECT DISTINCT c.tabschema, c.tabname, c.colname, c.colno,
c.typename, c.default, c.nulls, c.length, c.scale,
c.identity, tc.type AS tabconsttype, k.colseq
FROM syscat.columns c
...

This causes an exception like:
[IBM][CLI Driver][DB2/LINUXX8664] SQL0134N Improper use of a string column, host variable, constant, or function "DEFAULT". SQLSTATE=42907 SQLCODE=-134

The key problem here seems to be that you can't include a CLOB column in a select distinct.

At the very least, this breaks the command line tool for orm:schema-tool:update, although it might break other stuff too that I'm not aware of.

There's probably a cleaner query we can use, but I'm not familiar with the code base and what can/can't change. I don't want to introduce a bug, so I took the safe route and just did the ugly
subquery and join that shouldn't disturb anything. It's not like we need performance here.

I added a test which compares the results of the previous query with my new one. Seems to work. The test isn't something I expect to be added to your test suite - I figure someone else will run it manually to confirm my changes and then delete the test.






[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-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-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-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 23/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 BenMorel:

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

Message:

This is a first draft on the idea of a Transaction object, as suggested by @guilhermeblanco and @beberlei in doctrine/doctrine2#949.

This makes the following changes to `Connection`:

  • *Adds* the following methods:
  • `createTransaction()` : begins a transaction and returns the associated `Transaction` object
  • `getTransactionManager()` : returns the `TransactionManager`
  • *Deprecates* `beginTransaction()` in favour of `createTransaction()`
  • *Deprecates* the following methods, in favour of their counterparts on `Transaction`:
  • `commit()`
  • `rollBack()`
  • `setRollbackOnly()`
  • `isRollbackOnly()`
  • *Deprecates* the following methods, in favour of their counterparts on `TransactionManager`:
  • `isTransactionActive()`
  • `getTransactionNestingLevel()`
  • `setNestTransactionsWithSavepoints()`
  • `getNestTransactionsWithSavepoints()`

The new way of dealing with transactions is then:

$transaction = $connection->createTransaction();
$transaction->commit();

It also automatically propagates `commit()` and `rollback()` to nested transactions:

$transaction1 = $connection->createTransaction();
$transaction2 = $connection->createTransaction();
$transaction1->commit(); // will commit $transaction2 then $transaction1

Overall, it's not a complicated change, does not introduce any BC break, and passes all existing tests.

I'm looking forward to hearing what you think!



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

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





[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-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-704] [GH-444] DBAL-669 - Update SQL for generated by the schema tool will also create schemas Created: 13/Dec/13  Updated: 21/Aug/14  Resolved: 13/Dec/13

Status: Closed
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: Duplicate 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/444

Message:

DBAL-669 - Updating a schema should introduce also schema creation statements in the generated SQL



 Comments   
Comment by Marco Pivetta [ 13/Dec/13 ]

Duplicate of DBAL-669

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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





[DBAL-669] Postgresql platform schema creation fails if it already exists Created: 18/Nov/13  Updated: 21/Aug/14  Resolved: 18/Aug/14

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

Type: Bug Priority: Major
Reporter: Chris Ramakers Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

Postgresql 8.3.14 on CentOS6
Also happens on Postgresql 9.2 on the same box


Issue Links:
Reference
is referenced by DBAL-977 [GH-664] [DBAL-669] Make schema visit... Resolved

 Description   

This patch (https://github.com/doctrine/dbal/commit/fabe3c346b24dcb70eba0cb3936998ec6cc152f0) introduced a bug where the schemaNeedsCreation method always returns true if the schema name isn't 'default' or 'public'.

We heavily use schema's in our application and whenever an insert query is queued, it fails because the schema in question already exists but the platform adapter fails to detect that and continues with a "CREATE SCHEMA" query which fails.

The easy fix is to add the 'IF NOT EXISTS' clause to the 'CREATE SCHEMA' query but that will only function on Postgresql 9.3 and upward since 'IF NOT EXISTS' wasn't possible in earlier versions for schema creation.

Beter would be to load the existing schema's and compare them to those. I would create a pull request but i'm not sure how to obtain a database connection in the Platform (if at all possible) to pull a list of already known schema's?



 Comments   
Comment by Marco Pivetta [ 13/Dec/13 ]

Chris Ramakers I'm trying to look into it. The method

schemaNeedsCreation

seems indeed to be wrong.

Comment by Marco Pivetta [ 13/Dec/13 ]

Provided a fix for this at https://github.com/doctrine/dbal/pull/444

We won't fix the schema creation command, since it is supposed to fail on already existing conflicting elements (tables/etc)

Comment by Chris Ramakers [ 02/Apr/14 ]

Any news on this? The bug keeps causing problems every time we deploy a new version. We are practically required to edit the vendor files for doctrine in our project so this bug doesn't cause issues.





[DBAL-783] [GH-508] [DDC-2310] Fix evaluation of NOLOCK table hint on SQL Server Created: 13/Jan/14  Updated: 20/Aug/14  Resolved: 14/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 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 DDC-2310 Recent changes to DBAL SQL Server pla... Resolved
is referenced by DBAL-976 [GH-663] [DDC-2310] [2.4] Fix evaluat... Resolved

 Description   

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

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

Message:

This PR is complementary to https://github.com/doctrine/doctrine2/pull/910.
ORM passes `null` to `AbstractPlatform::appendLockHint()` as `$lockMode` which should not evaluated to `LockMode::NONE` unless `0` is explictly given. Otherwise ORM appends `WITH (NOLOCK)` to all queries even though, no query lock hint is set.



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

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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





[DBAL-976] [GH-663] [DDC-2310] [2.4] Fix evaluation of NOLOCK table hint on SQL Server Created: 20/Aug/14  Updated: 20/Aug/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





[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-900] [GH-600] Support for Partial Indexes for PostgreSql Created: 07/May/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

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

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

Issue Links:
Dependency
is required for DDC-3117 [GH-1027] Support for Partial Indexes... Open

 Description   

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

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

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual.



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

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

Comment by Doctrine Bot [ 16/May/14 ]

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

Comment by Doctrine Bot [ 02/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Aug/14 ]

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

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

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





[DBAL-563] Oracle "IDENTITY" last inserted ID is returning 0 instead of the real ID Created: 19/Jul/13  Updated: 18/Aug/14  Resolved: 31/Dec/13

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

Type: Bug Priority: Major
Reporter: Mohammad A. ZeinEddin Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: cascade, lastInsertedId, oci8, oracle
Environment:

Oracle, OCI8


Attachments: File LastInsertId.php     File OCI8Connection.php     File OCI8Statement.php    
Issue Links:
Reference
is referenced by DDC-2875 [GH-890] [DBAL-563] Add general IDENT... Resolved

 Description   

I am using doctrine 2 with oracle, the tables in the database has some triggers that generate the IDs, and I am trying to us Doctrine 2 cascade persist when mapping on one-to-many, and I use "IDENTITY" in the mapping, but there is a problem which is the one-side of the relation is returning 0 as last inserted ID, which is wrong, my ID mapping of my tables is like the following:

/**

  • @orm\Id
  • @orm\Column(type="integer");
  • @orm\GeneratedValue(strategy="IDENTITY")
    */
    protected $id;

and my entities looks like the following:

/**

  • @ORM\Entity
  • @ORM\Table(name="clients")
    **/
    class Client {
    /**
  • @ORM\Id
  • @ORM\GeneratedValue(strategy="IDENTITY")
  • @ORM\Column(type="integer")
    */
    protected $id;

/** @ORM\Column(name="name",type="string",length=255,unique=true) */
protected $name;

/**

  • @ORM\OneToMany(targetEntity="ContactInformation", mappedBy="client", cascade= {"persist"}

    )
    **/
    protected $contactInformations;

public function __construct()

{ $this->contactInformations = new ArrayCollection(); }

public function getId()

{ return $this->id; }

public function getName() { return $this->name; }

public function setName($name) { $this->name = $name; return $this; }

public function getContactInformations() { return $this->contactInformations; }

public function addContactInformations(Collection $contactInformations)
{
foreach ($contactInformations as $contactInformation) { $contactInformation->setClient($this); $this->contactInformations->add($contactInformation); }
}

/**
* @param Collection $tags
*/
public function removeContactInformations(Collection $contactInformations)
{
foreach ($contactInformations as $contactInformation) { $contactInformation->setClient(null); $this->contactInformations->removeElement($contactInformation); }
}

public function setContactInformations($contactInformations) { $this->contactInformations = $contactInformations; return $this; }
}

and the other entity:

/**
* @ORM\Entity
* @ORM\Table(name="contact_informations")
**/
class ContactInformation {
/**
* @ORM\Id
* @ORM\GeneratedValue(strategy="IDENTITY")
* @ORM\Column(type="integer")
*/
protected $id;

/**
* @ORM\OneToOne(targetEntity="ContactInformationType")
* @ORM\JoinColumn(name="type_id", referencedColumnName="id")
**/
protected $type;

/** @ORM\Column(type="text") */
protected $value;

/**
* @ORM\ManyToOne(targetEntity="Client", inversedBy="contact_informations")
* @ORM\JoinColumn(name="client_id", referencedColumnName="id")
**/
private $client;

public function getId() { return $this->id; }

public function getType()

{ return $this->type; }

public function setType($type)

{ $this->type = $type; return $this; }

public function getValue()

{ return $this->value; }

public function setValue($value)

{ $this->value = $value; return $this; }

public function getClient()

{ return $this->client; }

public function setClient($client = null)

{ $this->client = $client; return $this; }

}

I also want to add: why don't Doctrine 2 just use the oracle "returning id into" statement, in this case regardless the identity mapping this will always return the inserted ID, and it will work with "AUTO", "SEQUENCE", "IDENTITY" and I think any other mapping word used!

I did try to trace where the problem come from, and it seems that when using OCI8 oracle driver that the invoked method is
Doctrine\ORM\Id\IdentityGenerator::generate
and it invokes
Doctrine\DBAL\Connection::lastInsertId
and is returning 0, I don't know why it is being invoked since the sequenceName is null (there is no sequence in the definition!)

Maybe a good solution is to check if the $statement is an 'INSERT INTO ' sql statement, then we bind an output variable to the statement which will hold the "returning ID into :output_variable" value... what do you think?



 Comments   
Comment by Mohammad A. ZeinEddin [ 20/Jul/13 ]

I am not professional in Doctrine, but I want to suggest something to get the last inserted id for Oracle... I think this is even better than using the sequence name to get it... and it works for all types of ID generation methods...!

I think a good solution will be to do something like this in the "Doctrine\DBAL\Driver\OCI8\OCI8Statement::__construct" (may be there is a better place or way, this is just a suggestion), and make it like the following:
1- first we check if the statement is an insert statement then we add a ' returning id into :lastInsertId' sql, here we need somehow to get the primary key column name, data type length (max_length) and make it dynamic, 'id' is just the PK in my case...
2- we bind the ':lastInsertId' parameter so that we can get it as output parameter.

here is a sample code, maybe it needs a lot of enhancement

public function __construct($dbh, $statement, OCI8Connection $conn)
{
list($statement, $paramMap) = self::convertPositionalToNamedPlaceholders($statement);
if (stripos($statement, 'INSERT INTO ') === 0) {
$statement = $statement . ' returning id into :lastInsertId';
}
$this->_sth = oci_parse($dbh, $statement);
$this->_dbh = $dbh;
$this->_paramMap = $paramMap;
$this->_conn = $conn;
if (stripos($statement, 'INSERT INTO ') === 0) {
oci_bind_by_name($this->_sth, ':lastInsertId', $this->lastInsertId, OCI_B_INT);
}
}

and then when executing (execute method) we will have $this->lastInsertId set for us and containing the last inserted id even if it is from a sequence... can you implement such thing? and by this the "http://docs.doctrine-project.org/en/latest/reference/basic-mapping.html#identifier-generation-strategies" Identifier Generation Strategies "IDENTITY" will work for oracle and will be full portable

Comment by Mohammad A. ZeinEddin [ 20/Jul/13 ]

I just attached the suggested changes in OCI8 diver files, I just need help with 2 TODO issues, and I think then all will be fine

Comment by Stanislav Ivanov [ 01/Oct/13 ]

I'm suggesting this is a bug and not an improvement as it leads to different ORM behavior when using different database drivers.

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

Unfortunately the approach you suggested won't work as we are not able to identify the PK to return from the insert statement on the fly.

Comment by Mohammad A. ZeinEddin [ 24/Nov/13 ]

can't we get the column/s name/s from the mapping in the OCI8Statement.php file? isn't there anyway to do that? can you suggest an approad to do that? because the retuning id into :var is the right way to do that in oracle for all types of mapping!

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

Sure basically your approach is the way to go but I don't see a way how to determine the column name to return the last insert id for. The driver does not know what the identity column for a particular insert statement is.

Comment by Stanislav Ivanov [ 25/Nov/13 ]

Steve, I disagree. Oracle last insert id should not rely on identity column, instead, it should rely on current sequence value. And this is properly implemented in OCI8Connection (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php, lastInsertId method).

Besides, the proper triggers are implemented in OraclePlatform (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/OraclePlatform.php).

As I see in OraclePlatform::getCreateAutoIncrementSql() method, the sequence name is like following:

$table . '_SEQ'

So, I think that the problem is that EntityManager (or some lower level) does not provide the proper sequence name to OCI8Connection::lastInsertId() method causing it to trigger this code:

if ($name === null) {
    return false;
}

Please, check if it helps. As for now Doctrine ORM is literally unusable with Oracle.

Comment by Stanislav Ivanov [ 25/Nov/13 ]

Okay, seems, I've found the way it is correctly done (I had predefined sequence name, don't now if it working for entity-based generated schema):

    /**
     * @var int
     *
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     * @ORM\SequenceGenerator(sequenceName="seq_mytable", initialValue=75)
     */
    private $id;

So, we're using SEQUENCE generated value strategy for Oracle automatically and we fall back to manually defined sequence generator.

Just run persist() and flush() and got correctly set newly generated id. So cool.

Comment by Mohammad A. ZeinEddin [ 25/Nov/13 ]

This does not work for us, we are generating IDs automatically based on some triggers, so sequenceName does not work in our case... the only thing that I found working is by the modifications suggested up in the files...

Comment by Stanislav Ivanov [ 25/Nov/13 ]

It surely has nothing to do with Oracle driver as custom id field can be generated using triggers on every database.

So, you need to implement your brand new generated value strategy as it does not comply with IDENTITY and SEQUENCE documentation. It would be a nice extension.

Maybe this could help: http://ranskills.wordpress.com/2011/05/26/how-to-add-a-custom-id-generation-strategy-to-doctrine-2-1

Comment by Mohammad A. ZeinEddin [ 25/Nov/13 ]

As you see here:
http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#identifier-generation-strategies
the IDENTITY generation strategy is not implemented in Oracle... and I use it since the ID is generated bu the DB... so I think that it is better to change to the oracle way to get the last inserted ID when using this strategy...

Comment by Steve Müller [ 25/Nov/13 ]

IDENTITY generation strategy is SOMEHOW implemented in Oracle with the workaround of creating a (before insert) trigger on the specific table that uses a sequence to emulate an autoincrementation. I guess this is just a compatibility approach for IDENTITY strategy on a best effort basis and should not be relied on. This is also the reason why it is stated in the documentation as not fully portable. The issue discussed here is also not an issue of Doctrine ORM IMO as it is not responsible for evaluating if an IDENTITY strategy needs a sequence for the underlying driver to obtain the last insert ID. However there already seems to be hack for exactly the same case in PostgreSQL. See:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L453

What we probaby COULD do is add another check in the ClassMetadataFactory for the Oracle platform to tell it to use a sequence for IDENTITY strategy. But that still is rather hackish to be honest...

Comment by Benjamin Eberlei [ 13/Dec/13 ]

Steve Müller The real issue is indeed, that IDENTITY is not really supported for Oracle. We would need to find a way to support it generically or throw an exception in the ORM if Oracle is used with IDENTITY.

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

Step one in fixing this issue has been applied in PR https://github.com/doctrine/dbal/pull/428 and fixed in commit https://github.com/doctrine/dbal/commit/d2845256d22a0ea2c5e5392aa67f4b95f252d5c4.
Step two has been supplied in ORM in PR https://github.com/doctrine/doctrine2/pull/890.

As soon as the PR on ORM side gets merged it is possible to use IDENTITY generator strategy with Oracle

Comment by Doctrine Bot [ 31/Dec/13 ]

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

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

Fixed in commits:
https://github.com/doctrine/dbal/commit/d2845256d22a0ea2c5e5392aa67f4b95f252d5c4
https://github.com/doctrine/doctrine2/commit/a7b9140d2fddcab995b2597be4d589155ff1aa8f





[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-630] Incorrect PostgreSQL boolean handling Created: 14/Oct/13  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Critical
Reporter: Stan Imbt Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This is a follow-up to issue #457 ("Use int values instead of strings for PostgreSQL booleans"), which is still not fixed. Int values are no solution at all. In fact the root cause lies deeper, outside the PostgreSQL platform class.

1. The patch to fix #457 does not change the default behaviour of the PostgreSQL platform class (method convertBooleans() returns strings 'true'/'false'). When the PostgreSQL PDO driver is configured to emulate prepared statements, it still results in unexpected failures, storing boolean false entity values as true in the database.

2. The new alternative boolean conversion mode activated by PostgreSqlPlatform::setUseBooleanTrueFalseStrings(false) is of no use as it prevents execution of DQL queries with boolean conditions, because integers 0 and 1 are not valid boolean literals in PostgreSQL.

The root cause is the notion of a PHP value being convertible to a database value. Because in fact there are two different types of "database values":

  • Literals used directly in SQL statements
  • Values passed as parameters to prepared statements

To make this absolutely clear:

Prerequisites
$pdo = new PDO(...);
$pdo->exec('CREATE TABLE my_table(bool_col BOOLEAN NOT NULL)');
$stmt = $pdo->prepare('INSERT INTO my_table(bool_col) VALUES(?)');
Using string 'false'
$value = 'false';

// This works, using the SQL literal false
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// This works, too. But it's remarkable that Postgres accepts the string 'false'
// as a boolean value. Compare this to the string 'NULL' in an SQL statement vs.
// 'NULL' as a prepared statement param (instead of PHP null).
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Sets bool_col to true! The PostgreSQL PDO driver correctly expects a boolean
// and (string)'false' yields true.
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();
Using boolean false
$value = false;

// This will obviously fail, because false is cast to an empty string, resulting
// in "... VALUES()".
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// Works
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Works, too
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();
Using integer 0
$value = 0;

// Causes 'ERROR: column "bool_col" is of type boolean but expression is of type integer'
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// Works
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Works, because of implicit PHP type cast 0 -> false
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

There are two locations in DBAL and ORM where AbstractPlatform::convertBooleans() is called to build SQL literals:

DoctrineDBALPlatformsAbstractPlatform::getDefaultValueDeclarationSQL()
$default = " DEFAULT '" . $this->convertBooleans($field['default']) . "'";

Wow, this is even being enclosed in single quotes!? But then the whole method is buggy anyway, e.g. using an unescaped string value for a string literal (scenarios for SQL injection unlikely but possible).

DoctrineORMQuerySqlWalker::walkLiteral()
case AST\Literal::BOOLEAN:
	$bool = strtolower($literal->value) == 'true' ? true : false;
	$boolVal = $this->conn->getDatabasePlatform()->convertBooleans($bool);
	return $boolVal;

...and the result is later used as a boolean literal in an SQL query.

To solve this we need something like AbstractPlatform::convertBoolToSqlLiteral() (returning strings true and false for the Postgres platform) and AbstractPlatform::convertBoolToDbValue() (converting to integer 0 or 1 for platforms without a native bool type).

Note 1: The docs currently suggest to call $conn->getDatabasePlatform()->setUseBooleanTrueFalseStrings($flag). This is bad OO design, because getDatabasePlatform() returns an AbstracPlattform instance which does not have a contract for the method.

Note 2: What makes this problem so nasty is the fact that switching to emulated prepares makes an application fail in a non-obvious way. There will be no traceable errors but simply all boolean false values in ORM entities stored as boolean true. When integration tests use a different database (e.g. an SQLite in-memory DB to minimize test execution time) the problem will even escape the tests. And the distance between cause and effect also makes the problem very hard to find. Who would expect a database driver setting to cause booleans in the DB to be the opposite of what they're supposed to be? Especially as this only becomes apparent after later re-hydrating stored entities.

Note 3: Why emulated prepared statements matter: When PostgreSQL processes a prepared statement, its query planner works out a query plan and uses it for all subsequent executions of this query. This way it has to make a rather crude guess at the number of affected rows from each table in a join. When a non-prepared query is executed, the query planner can take into account the given values (mostly the ones in the "WHERE" part of the query) and make a much more specific guess at which plan will perform best.
In our case, we decided to switch to emulated prepares after we found out that a complex query in our application would run five times faster with emulated prepares.

Note 4: Is there a reason for AbstractPlatform::convertBooleans() accepting either a single bool value or an array of bool values? I didn't find client code calling it with an array. This makes the method less obvious, is currently implemented with code duplication and at least for the PostgreSQL plattform class, the "array of bool" functionality is not even tested.



 Comments   
Comment by Benjamin Eberlei [ 01/Jan/14 ]

PDO::ATTR_EMULATE_PREPARES finally explains why I was unable to reproduce this before. This is obviously a very critical error. Increasing priority.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

Stan Imbt I cannot really reproduce the ATTR_EMULATE_PREPARES issue, see https://github.com/doctrine/dbal/commit/f29f0fae8479955911928888ebab07ccd4e8ab0c

I agree that we need two methods on the Platform for casting values to SqlLiterals and to Params, as they are in two different contexts.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

We have a reproduce-case, it fails on Travis: https://travis-ci.org/doctrine/dbal/jobs/16217622

Comment by Stan Imbt [ 02/Jan/14 ]

Thanks for looking into this, Benjamin.
We could reproduce the problem with different PHP 5.4 builds on both Linux and Windows (Postgres version shouldn't matter as emulated prepares are handled in the Postgres PDO driver). Travis runs the tests on PHP 5.3 and also fails as expected. Are you using PHP 5.5? If so, I assume the PHP folks have recently changed the PG PDO driver's behaviour, making it act more like PG itself (i.e. converting a bool param with string value 'false' to boolean false).

Comment by Davi Koscianski Vidal [ 31/Mar/14 ]

I'm using PHP 5.5.3 + PostgreSQL 9.3.3 and I confirm that this is not working.

But it looks like it won't work for anyone because PHP: https://bugs.php.net/bug.php?id=57157.

Comment by Stan Imbt [ 01/Apr/14 ]

Davi, I can reproduce the referenced PHP bug, both with and without emulated prepares, but it is not related to this Doctrine bug.

Doctrine calls PDOStatement::bindValue(), specifying the data type PDO::PARAM_BOOL in case of bool fields. The PHP bug only occurs when the param data type is not provided, apparently converting the param value to string ((string)false === '') and passing that on to the DBMS.

Comment by Davi Koscianski Vidal [ 01/Apr/14 ]

Stan, almost the same 'test case' as PHP bug:

<?php

/*
CREATE TABLE "booleantest" (
  "persistence_object_identifier" serial NOT NULL,
  "hidden" boolean NOT NULL
);
 */

$handle = new PDO('pgsql:host=127.0.0.1 dbname=postgres', 'postgres', 'postgres');
$handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$handle->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$handle->setAttribute(PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT, true);

$statement = $handle->prepare('INSERT INTO booleantest (hidden) VALUES (?)');

// works as expected
$statement->execute(array(true));
echo 'TRUE has been inserted' . PHP_EOL;

$statement->bindValue(1, "true", PDO::PARAM_BOOL);
echo 'TRUE has been inserted' . PHP_EOL;

// dies with
// PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: ""
// $statement->execute(array(FALSE));

$statement->bindValue(1, "false", PDO::PARAM_BOOL);
$statement->debugDumpParams();
$statement->execute();
echo 'FALSE has been inserted' . PHP_EOL;

When PDO::ATTR_EMULATE_PREPARES is set to true, $stmt->debugDumpParams() outputs:

SQL: [43] INSERT INTO booleantest (hidden) VALUES (?)
Params:  1
Key: Position #0:
paramno=0
name=[0] ""
is_param=1
param_type=2

But when it is disabled, it outputs:

SQL: [43] INSERT INTO booleantest (hidden) VALUES (?)
Params:  1
Key: Position #0:
paramno=0
name=[0] ""
is_param=1
param_type=5

This is exactly the same output from tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php (after adding debugDumpParam() to DBAL\Driver\PDOStatement.php, obviously). param_type = 2 when type = PDO::PARAM_STR.
For debugging purposes, I changed DBAL\Driver\PDOStatement.php line 67 from return parent::bindValue($param, $value, $type); to parent::bindValue(1, "false", \PDO::PARAM_BOOL); (so I will always store a boolean false on database), but debugDumpParam() keeps telling me that param_type is 2 if I'm using emulated prepares.

Comment by Davi Koscianski Vidal [ 01/Apr/14 ]

Using $stmt->bindValue(1, 'false', \PDO::PARAM_STR); works as expected. Maybe a dirty workaround?

Comment by Davi Koscianski Vidal [ 03/Apr/14 ]

This same test case passes with PHP 5.3.18, but fails with 5.5.3 and 5.5.11.

$ phpenv shell 5.5.11

$ php --version
PHP 5.5.11 (cli) (built: Apr  3 2014 09:52:27) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from.postgres.phpunit.xml

..F

Time: 3.91 seconds, Memory: 4.25Mb

There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\Ticket\DBAL630Test::testBooleanConversionBoolParamEmulatedPrepares
Failed asserting that true is false.

./tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php:79

FAILURES!
Tests: 3, Assertions: 6, Failures: 1.

$ phpenv shell system 

$ php --version
PHP 5.5.3-1ubuntu2.2 (cli) (built: Feb 28 2014 20:06:05) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
    with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from ./postgres.phpunit.xml

..F

Time: 1.59 seconds, Memory: 4.25Mb

There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\Ticket\DBAL630Test::testBooleanConversionBoolParamEmulatedPrepares
Failed asserting that true is false.

./tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php:79

FAILURES!
Tests: 3, Assertions: 6, Failures: 1.

$ phpenv shell 5.3.18 

$ php --version
PHP 5.3.18 (cli) (built: Apr  2 2014 16:47:04) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from ./postgres.phpunit.xml

...

Time: 1.06 seconds, Memory: 6.50Mb

OK (3 tests, 6 assertions)
Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

I think I messed something when creating the PR. The bot automatically created this ticket: http://www.doctrine-project.org/jira/browse/DBAL-863

I'm sorry.

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

Fixed in PR: https://github.com/doctrine/dbal/pull/625
Commit: https://github.com/doctrine/dbal/commit/5eb36c7a643d5e44f0eee4ca39e56088527ce146





[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-949] [GH-636] Update SQLSrvStatement.php Created: 22/Jul/14  Updated: 08/Aug/14  Resolved: 08/Aug/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 bouland:

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

Message:

I would like to extends functionnality of the driver.

Feel free to explain me if there is better pattern to add behavior.
May be getters and setters ?

I m using DBAL in Symfony 2.

I would like to add specific functionnality and re use DBAL connection.



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

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





[DBAL-446] Type json_array can't be null Created: 13/Feb/13  Updated: 06/Aug/14

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

Type: Bug Priority: Major
Reporter: Jan Hruban Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-966 [GH-655] json_array columns should re... Resolved

 Description   

Column type json_array can be set to nullable, but if there's null in the database, it is returned as an empty array to PHP.

Null should be returned instead, as that's how the other types behave too.



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

This was fixed in 2.3.3

Comment by Joseph Wynn [ 06/Aug/14 ]

I'm seeing this behaviour again in v2.5.0-BETA3 (6d0b048). If I get time this week I can perform a bisect to figure out when it regressed.

Comment by Joseph Wynn [ 06/Aug/14 ]

Actually I don't think this was a regression; it looks like a fix was never made. I've opened a PR: https://github.com/doctrine/dbal/pull/655

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Marco Pivetta [ 06/Aug/14 ]

Re-opened, as this behavior seems reproducible also in 2.4.x

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

It was never fixed. That seems to have been a misunderstanding here. As pointed out by Marco Pivetta changing this behaviour is a BC break and can't be fixed before 3.0.





[DBAL-451] [GH-276] DBAL-446 Created: 19/Feb/13  Updated: 06/Aug/14  Resolved: 06/Apr/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

Fix for DBAL-446 with a proper test case and two general test cases.



 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 Doctrine Bot [ 06/Aug/14 ]

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





[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-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-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-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-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-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-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   
Comment by Doctrine Bot [ 31/Jul/14 ]

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





[DBAL-889] [GH-590] Add a select method to Connection Created: 30/Apr/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: 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 JeroenDeDauw:

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

Message:

This is a draft; it has not been tested, not even manually.
It is meant for conceptual review



 Comments   
Comment by Doctrine Bot [ 30/Apr/14 ]

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

Comment by Doctrine Bot [ 30/Apr/14 ]

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

Comment by Doctrine Bot [ 31/Jul/14 ]

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





[DBAL-955] No exception thrown for query error Created: 31/Jul/14  Updated: 31/Jul/14

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

Type: Bug Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

SQL Server 2012



 Description   

Consider the following code:

IF OBJECT_ID('tempdb..#TestTable') IS NOT NULL DROP TABLE #TestTable

CREATE TABLE #TestTable
( 
id INT  NOT NULL IDENTITY(1,1) PRIMARY KEY, 
aDate DATETIME2(6) NULL
)

INSERT INTO #TestTable
(
aDate
) VALUES
(
'2014-07-30 08:54:23.000000'
)

SELECT *
FROM #TestTable
WHERE aDate > 2000

Error:

Msg 206, Level 16, State 2, Line 21
Operand type clash: datetime2 is incompatible with smallint

Problem: for this error no DBALexception is thrown

By the way, this does work (but does not affect problem description):

SELECT *
FROM #TestTable
WHERE aDate > '2000'


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

Flip your code example includes no DBAL code: could you also add the PHP wrapping around those SQL statements?





[DBAL-954] Custom QuoteStrategy doesn't work when creating new schema Created: 30/Jul/14  Updated: 30/Jul/14

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

Type: Bug Priority: Minor
Reporter: Piotr Łyczba Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Implementing custom quote strategy:

class SingleQuoteStrategy extends DefaultQuoteStrategy implements QuoteStrategy
{
    public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform)
    {
        return isset($class->fieldMappings[$fieldName]['quoted'])
            ? $platform->quoteSingleIdentifier($class->fieldMappings[$fieldName]['columnName'])
            : $class->fieldMappings[$fieldName]['columnName'];
    }
}

doesn't work when a new schema is created.

The problem is that in class file mapping I have column that has dot in its name escaped with back single quotes:

<field name="anuncianteId_delete" type="integer" column="`anunciante_id.delete`" nullable="true"/>

My custom quote strategy is necessary to force Doctrine to respect that. Otherwise Doctrine treats it as: namespace.name.

If I already have table with that column in my database update schema tool doesn't complains, the problem occurs only when I try to create new schema.

The error in resulting SQL Statement:

(SQLSTATE[HY000]: General error: 1 near ".": syntax error' while executing DDL: CREATE TABLE account ( (...) "anunciante_id"."delete" INTEGER DEFAULT NULL, (...) )





[DBAL-950] [GH-637] Backport #625 - pgsql boolean conversion Created: 22/Jul/14  Updated: 29/Jul/14  Resolved: 29/Jul/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 sergeyz:

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

Message:



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

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





[DBAL-539] [GH-332] [DDC-2470] Use column name instead of alias to modify order by clause Created: 05/Jun/13  Updated: 28/Jul/14  Resolved: 07/Jun/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
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 FabioBatSilva:

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2470



 Comments   
Comment by Doctrine Bot [ 07/Jun/13 ]