[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-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-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 13/Nov/14

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 5
Labels: None


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 28/Dec/13

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

Type: Bug Priority: Minor
Reporter: Jürgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0



 Description   

In the example in the documentation http://doctrine-dbal.readthedocs.org/en/2.0.x/reference/data-retrieval-and-manipulation.html#dynamic-parameters-and-prepared-statements there is the following example:

$sql = "SELECT * FROM users WHERE name = :name OR username = :name";
$stmt = $conn->prepare($sql);
$stmt->bindValue("name", $name);
$stmt->execute();

When I try this example using pdo_sqlsrv I get the following error:
PDOException: SQLSTATE[07002]: [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error

When I use instead the parameters name1 and name2 the query works as expected.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?

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

Jürgen ping. I cannot reproduce this error, either. Can you please try to reproduce this with the latest master branch? Otherwise I will close this ticket.





[DBAL-700] [GH-441] Fixed renaming of MSSQL columns Created: 09/Dec/13  Updated: 17/Dec/13  Resolved: 17/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: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Column renaming supports tables with same name in multiple schemas



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

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





[DBAL-481] [GH-297] check for proper type when formatting dates Created: 02/Apr/13  Updated: 02/Apr/13  Resolved: 02/Apr/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:



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

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





[DBAL-465] [GH-286] Fix data not being cached in ResultCache Created: 19/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

The ResultCacheStatement has a small logic error, it tested for emptied
being true when it should have tested for emptied being false. The
comments also statement that the function returns a boolean, however the
function didn't return a boolean.

This is my first time committing to a larger open source project like dbal. Very worried I'll of done something wrong, please go easy / teach me.



 Comments   
Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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





[DBAL-456] [GH-279] adds new output format Created: 03/Mar/13  Updated: 05/Mar/13  Resolved: 05/Mar/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: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

The output of the ::dump command is very unstable (depends on platform/PHP version/installed extensions).

This pull request adds a new format which is more suitable for machine consumption.



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

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





[DBAL-454] [GH-277] Remove duplicate SQL parts in query generation Created: 02/Mar/13  Updated: 20/Aug/13  Resolved: 03/Mar/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: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Presently, it's possible to do this using QueryBuilder:

```php
$qb->select('u.*')
->from('users', 'u')
->addOrderBy('u.name', 'ASC')
->addOrderBy('u.name', 'ASC'); // duplicate
```
Which produces:
```sql
SELECT u.* FROM users u ORDER BY u.name ASC, u.name ASC
```

This patch removes duplicates from the `SELECT`, `SET`, `ORDER BY` and `GROUP BY` parts during SQL generation (there's already logic that removes duplicate `FROM` parts).

I've added test cases for each affected keyword as well.



 Comments   
Comment by Benjamin Eberlei [ 03/Mar/13 ]

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

Comment by Doctrine Bot [ 20/Aug/13 ]

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





[DBAL-426] [GH-256] Create queryBuilder from parts. Created: 25/Jan/13  Updated: 26/Jan/13  Resolved: 26/Jan/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Add a feature that can create a queryBuilder from queryBuilder parts.

This can be used when a query is build and needs to be stored somehow and restore it later.



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

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





[DBAL-414] zaza Created: 09/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

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

Type: Bug Priority: Major
Reporter: batbileg Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

aaan



 Description   

yu



 Comments   
Comment by batbileg [ 09/Jan/13 ]

yu wm





[DBAL-391] [GH-233] convertToPHPValue should match convertToDatabaseValue Created: 23/Nov/12  Updated: 03/Dec/13  Resolved: 23/Nov/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

convertToPHPValue return resource which is not match default convertToDatabaseValue that not make and change. Change to return content of the resource.



 Comments   
Comment by Marco Pivetta [ 23/Nov/12 ]

Blob field types should be converted to resources:
https://travis-ci.org/doctrine/dbal/jobs/3329007/#L77

Comment by Benjamin Eberlei [ 26/Nov/12 ]

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

Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DBAL-376] [GH-223] Include customSchemaOptions in column mapping Created: 05/Nov/12  Updated: 14/Jan/13  Resolved: 14/Jan/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: 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 djlambert:

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

Message:

This PR adds the customSchemaOptions in the array passed to the type.



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

Solved in DBAL-413





[DBAL-368] array and object types should use BLOB, not CLOB, to store serialized data Created: 19/Oct/12  Updated: 20/Dec/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Major
Reporter: Karsten Dambekalns Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: postgresql


 Description   

When using array or object types, PHP's serialize() is used. Since that can return NUL bytes, using a text type will fail at least on PostgreSQL (just search the web for issues of that kind…).

So ArrayType and ObjectType should return a BLOB definition instead of a CLOB definition to be binary-safe.



 Comments   
Comment by Karsten Dambekalns [ 19/Oct/12 ]

See DBAL-369 for the suggested fix

Comment by Marco Pivetta [ 23/Jan/13 ]

Karsten Dambekalns DBAL-368 is this issue. What's the one you were referring to?

Comment by Marco Pivetta [ 23/Jan/13 ]

Nvm, it was DBAL-369

Comment by Marco Pivetta [ 23/Jan/13 ]

Moved to DBAL-369

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-333] [GH-193] Add DBAL\TypeAwareObject. Created: 29/Aug/12  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Romain-Geissler:

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

Message:

This PR adds a common interface for custom object values that requires some PHP <-> SQL conversions, which allows to specify what DBAL type must be used for conversion.



 Comments   
Comment by Benjamin Eberlei [ 30/Aug/12 ]

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





[DBAL-327] [GH-188] Akiban driver Created: 24/Aug/12  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

An initial implementation of a driver for the [Akiban Server](http://www.akiban.com/akiban-server). You will notice in the diff there are some features Akiban does not yet support in its latest release but are planned for future releases.

I wasn't sure if pull request was the best way to start a dialog to get this work accepted or whether the mailing list is more appropriate. Please let me know and I will do as suggested.

I am an engineer at Akiban and am very willing to maintain/improve this driver.



 Comments   
Comment by Benjamin Eberlei [ 27/Aug/12 ]

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

Comment by Padraig O'Sullivan [ 28/Aug/12 ]

Yes, this ticket has been superseded by ticket 330.





[DBAL-308] [GH-174] Used the placeholder in the command help for the name Created: 16/Jul/12  Updated: 23/Jul/12  Resolved: 23/Jul/12

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

Message:

This change will allow to keep the original help message in DoctrineBundle even if we rename the command. I will submit the same PR for the ORM.

@beberlei please include it in the 2.3 branch (and ideally in 2.2 if it is not too much to ask for it). My goal is to stop duplicating the help messages in the bundle as outdated help messages are really a pain for users (see doctrine/DoctrineBundle#89)



 Comments   
Comment by Benjamin Eberlei [ 23/Jul/12 ]

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





[DBAL-291] [GH-157] interface compatibility Created: 01/Jun/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

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


 Description   

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

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

Message:






[DBAL-260] [GH-135] Add typehint info to core types for use by entity generator. Created: 18/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

So as you probably know, the EntityGenerator doesn't typehint the setters for the DateTime types (datetime, date, datetimetz, time) - which has just caused me to miss an obvious error, and judging from google, plenty of others before me too.

So I've added it - you'll have a pull request in a sec on the doctrine2 repo for that, but it needs this change too - which provides the mapping info.



 Comments   
Comment by Benjamin Eberlei [ 26/Apr/12 ]

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





[DBAL-258] [GH-133] Removed Paranthesis to allow for more complex Regex Created: 17/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Needed to remove the Paranthesis to allow excluding of Tables with more complex Regular Expressions.



 Comments   
Comment by Benjamin Eberlei [ 17/Apr/12 ]

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





[DBAL-253] [GH-132] Added Support for excluding Tables Created: 10/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 18/Apr/12 ]

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





[DBAL-246] [GH-125] PHPDoc blocks improvments + 1 CS Fix Created: 02/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed 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/125

Message:

Hey guys,

I started to fix a class type inside Connection and then i went ahead to see what i could also improve!

Adrien



 Comments   
Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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





[DBAL-226] DATETIME2 in MSSQL - declared, but not supported Created: 20/Feb/12  Updated: 05/Mar/12  Resolved: 05/Mar/12

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

Type: Bug Priority: Major
Reporter: ross neacoders Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

From Doctrine documentation

27. Limitations and Known Issues
...
27.2.2. Microsoft SQL Server and Doctrine "datetime"
Doctrine assumes that you use DateTime2 data-types. If your legacy database contains DateTime datatypes then you have to add your own data-type (see Basic Mapping for an example).

In reality, the type is not supported, failing with exception

Could not convert database value "2012-02-15 01:25:12.0000000" to Doctrine Type datetime. Expected format: Y-m-d H:i:s.u

The reason of such behavior is a bug in DBAL
MsSQLPlatform::getDateTimeFormatString => 'Y-m-d H:i:s.u'

u (milliseconds in PHP) occupy 6 digits, while datetime2 type has 7 digits.
The solution is to truncate last digit before conversion



 Comments   
Comment by Benjamin Eberlei [ 03/Mar/12 ]

cCtually it is supported, when the DATETIME2 are created through Doctrine, because it makes DATETIME2(6) out of them to make DateTime#createFromFormat() support work. I am not sure how to fix this problem with "datetime" type, it will work when you use the VarDateTime types, these are a bit slower, but dont have this problem. Just call this in your bootstrap:

\Doctrine\DBAL\Types\Type::overrideType("datetime", "Doctrine\DBAL\Types\Type\VarDateTime");
Comment by ross neacoders [ 05/Mar/12 ]

Beberlei,

This issue is related to datetime2 MSSQL type (NOT datetime MSSQL type).

Datetime2 is declared, but not supported - read above again.

Comment by Benjamin Eberlei [ 05/Mar/12 ]

I read your comment and did speak about DATETIME2.

DATETIME in MsSQL only has 3 digits after the second. DATETIME2 by default has 7. However PHPs DateTime#createFromFormat() only supports 6 digits. That is why Doctrine creates MsSQL DATETIME2(6) columns, restricting to 6 digits. If your database already has DAteTime2 columns with 7 digits, then you have to register the VarDateTime type as detailed in my comment above.

Comment by ross neacoders [ 05/Mar/12 ]

Understand, you mentioned "datetime" in your post, so I thought you misunderstood the issue.

But, isn't checking if DATETIME2 is (7) and truncating last digit not a better option, if VarDateTime and date_create have bad speed?
VarDateTime seems to work, but last 7th digit is not considered anyway.
Also this will eliminate need to change something in bootstrap.





[DBAL-159] Symfony Doctrine Task "doctrine:database:create" fails with "Undefined index: dbname" Created: 25/Aug/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

Status: Closed
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Anderson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Symfony 2.0, Doctrine 2.1, PHP 5.3.8 and Oracle 11g-R2 Enterprise



 Description   

For some reason,when attempting to create a database, the doctrine:database:create task fails complaining that the "dbname" parameter is not found. Printing the $params var from the file "vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/PDOOracle/Driver.php" indeed shows that the dbname array element is not present. However, it is present in the app/config/parameters.ini (as database_name).

The following is the method from PDOOracle/Driver.php where the missing "dbname" index is used a few times... adding the dbname with an appropriate value
allows the dsn to get created - but Oracle then throws an ORA-00911 error indicating an invalid character in the PDO statement... However, I'm able to use the output of _constructPdoDsn( ) in a simple standalone connect script (provided below) successfully.

    private function _constructPdoDsn(array $params)
    {
        $params['dbname'] = 'pmdb0';  // Inserted for testing by Ed Anderson
        $dsn = 'oci:';
        if (isset($params['host'])) {
            $dsn .= 'dbname=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)' .
                   '(HOST=' . $params['host'] . ')';

            if (isset($params['port'])) {
                $dsn .= '(PORT=' . $params['port'] . ')';
            } else {
                $dsn .= '(PORT=1521)';
            }

            $dsn .= '))(CONNECT_DATA=(SERVICE_NAME=' . $params['dbname'] . ')))';
        } else {
            $dsn .= 'dbname=' . $params['dbname'];
        }

        if (isset($params['charset'])) {
            $dsn .= ';charset=' . $params['charset'];
        }

        print( $dsn ); // Inserted to extract the constructed DSN and test in an external php script...
        return $dsn;
    }

-------- Script created using the output of _constructPdoDsn( ) follows ----- This script works fine...

$dsn = 'oci:dbname=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=pmdb0.mydomain.net)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=pmdb0)));charset=UTF8';
$user = 'pmcore';
$pass = 'mypaswd';

try
{
    $dbh = new PDO( $dsn, $user, $pass );

    if( $dbh )
    {
        print( "Connected to PDO using: " . $dsn . "\n");
        unset( $dbh );
    }
}

catch( PDOException $e )
{
    print( "ERROR: " . $e->getMessage( ) );
    die( );
}

---------------- End Test Script -------------



 Comments   
Comment by Ed Anderson [ 25/Aug/11 ]

Running the task doctrine:schema:create --dump-sql produces output that will correctly build the tables in the database manually... but this is not ideal obviously. Still can't seem to find where the "invalid character" is showing in the statement generated by the PDOOracle Driver or some other file in the DBAL.

Comment by Guilherme Blanco [ 17/Sep/11 ]

Formatted ticket

Comment by Benjamin Eberlei [ 30/Oct/11 ]

I would advise against using the PDO Oracle driver, as PDO Oracle has bugs and it is not maintained anymore, not even by Oracle. OCI8 is the way to go.

Also creating a database is not supported in Oracle, since there is no concept database.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

The parameter name has to be "dbname" in symfony also.





[DBAL-156] Github-PR-44 by richardfullmer: [PostgresPlatform] Fixing change detection when a default is removed Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Change detection when the default value is removed from a field is presently broken and produces invalid SQL.

This patch checks to see if a new default value actually exists before adding the SET DEFAULT '';

Uses DROP DEFAULT when the new default value does not exist






[DBAL-155] Github-PR-46 by gnomii: 2.1.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime



 Comments   
Comment by Steve Müller [ 20/Nov/13 ]

PR was closed





[DBAL-154] Github-PR-47 by gnomii: 2.0.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime






[DBAL-77] Mysql Numeric / Decimal fields Created: 13/Dec/10  Updated: 04/Jan/13  Resolved: 15/Mar/12

Status: Closed
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA4, 2.0, 2.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugene Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 2
Labels: None
Environment:

mysql 5.1.49 for debian-linux-gnu (x86_64), Ubuntu 10.10 Doctrine DBAL Beta4 Doctrine ORM Beta4 Doctrine Common RC1



 Description   

class product {
/**
*Column(type="decimal", scale="2")
*
*/
private $discount;
}

generate SQL

create table product {
discount DECIMAL(10,2) NOT NULL
}

if you have a field in a database type DECIMAL doctrine tries to
generate for him diff

doctrine orm:schema-tool
>
ALTER TABLE product CHANGE discrount discrount NUMERIC (10, 2) NOT NULL

but mysql ignore the alter, as a result of these diff stretch from
migration to migration



 Comments   
Comment by Benjamin Eberlei [ 13/Dec/10 ]

This is fixed in RC1 or RC2.

Comment by Eugene [ 20/Jan/11 ]

checked for the version of doctrine 2.1.0-DEV
result is the same

Comment by Oleg Anashkin [ 31/Jan/11 ]

I have the same issue with the latest doctrine build. Please fix it because it makes schema migration scripts dirty with redundant changes.

Comment by Benjamin Eberlei [ 04/Mar/11 ]

I cannot reproduce this, does this happen if you also specify precision=10 ?

Comment by Alexander [ 15/Mar/12 ]

Closing until someone can provide more feedback.

Comment by Joel Simpson [ 04/Jan/13 ]

I am seeing this bug for a definition specified as:

  • @ORM\Column(type="decimal", precision=20, scale=0, nullable=false, unique=true)

Doctrine Command Line Interface version 2.3.2-DEV





[DBAL-48] Doctrine\DBAL\Platforms\MsSqlPlatform Incorrect Offset Limit Sql Created: 04/Sep/10  Updated: 14/Nov/10  Resolved: 14/Nov/10

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

Type: Bug Priority: Major
Reporter: Scott Connelly Assignee: Juozas Kaziukenas
Resolution: Invalid Votes: 0
Labels: None
Environment:

All MSSQL



 Description   

The way the offset query is constructed (line 473) it always pulls the top records from the query even when and offset is present, so if you have an offset of 0 and limit of 10 you get the first 10 records. When you change the offset to 5 you still get the first 10 records from the original query. This issue was also in the 1.2 driver code.

This is basically what gets created when an offset is present with a limit of 10 and an offset of 5 :
SELECT * FROM
(SELECT TOP 10 * FROM
(SELECT TOP 15
col1, col2, colN FROM table
) AS [inner_tbl]
) AS [outer_tbl]

The fix is to reconstruct the query to remove the outer_tbl SELECT TOP and make it something like the following:
SELECT * FROM (
SELECT TOP [limit] ROW_NUMBER() OVER (ORDER BY [primary_key]) as RowNum, col1, col2, colN FROM table
) as [inner_tbl] WHERE [inner_tbl].RowNum BETWEEN [offset] AND [limit + offset]



 Comments   
Comment by Juozas Kaziukenas [ 14/Nov/10 ]

This is fixed in current master https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MsSqlPlatform.php#L555

Unless this ticket is referring to Doctrine 1





[DBAL-332] Memory option for Sqlite driver does nothing Created: 29/Aug/12  Updated: 04/Jun/14  Resolved: 17/Sep/12

Status: Closed
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2, 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Damien ALEXANDRE Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP Version 5.3.10
SQLite Library 3.7.9
Doctrine 2.3.x-dev
Dbal 2.3.x-dev
Symfony 2.1 RC2



 Description   

I'm trying to configure a "memory" sqlite database, as described here: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#pdo-sqlite

So here is my configuration (config_test.yml) :

Unable to find source-code formatter for language: yml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
doctrine:
    dbal:
        driver:    pdo_sqlite
        memory:    true
        user:      db_user
        password:  db_pwd
        charset:   UTF8

I'm then running

./app/console doctrine:database:create --env=test

and the result is a "myBdName" db file (the filename contains the quote!!) in my root folder.

I don't understand why the file http://www.doctrine-project.org/api/dbal/2.3/source-class-Doctrine.DBAL.Schema.SqliteSchemaManager.html#46 is creating a path option with my DB name, if I comment the line 57, everything seems fine (no more file created).

I have seen some memory related options in the Doctrine test suite so maybe I'm doing it wrong, and in that case that's a documentation issue I can work on.

Thx,
Damien



 Comments   
Comment by Benjamin Eberlei [ 05/Sep/12 ]

You cannot create an in memory database using Symfonys database:create. The in memory database will be closed when the request ends. So its completly useless this way. You have to recreate it in every request that you want to use it. It is just good for one request.

Comment by Damien ALEXANDRE [ 06/Sep/12 ]

My example with "app/console" is misleading,
what I want to do is building a memory SQLite database on the fly and run some code right after it (in a phpunit test).

The issue here is that there is an option documented (first link) that doesn't work / is not implemented (second link). And a physic file is generated, it should not.

As your answer seems to be based on the mistaken impression that I wanted to use volatile database in a persistent way, I'm reopening this issue.

Thanks for your time.
Damien.

Comment by Benjamin Eberlei [ 07/Sep/12 ]

Try removing the user/password keys. memory database connection works for me, this seems to be a configuration issue.

If you want to create an in memory db for testing then you have to create the schema with SchemaTool inside the phpunit tests.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

No feedback on potential fix, this issue is either misconfiguration or wrong use of the API. I couldn't reproduce this and it works for me (TM).

Comment by Iain Potter [ 04/Jun/14 ]

Hi guys, this does not work for me either. Same use case.

Config:

driver: pdo_sqlite
memory: true

Comment by Iain Potter [ 04/Jun/14 ]

Apologies for resurrecting an old issue but a google search brought me here.





[DBAL-921] [GH-616] Always store dates in UTC Created: 11/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

This PQ will make sure that the dates saved in the database (without indication of timezone) is always stored in the UTC timezone.

I was doing development on my machine in Sweden when I noticed that when I created a `DateTime`, stored it in the db and then retrieved it again, the time was off by two hours. This is because a created the `DateTime` object with the UTC timezone. Doctrine then saved it straight to the database (by using `$date->format(...)`) and thus the information about which timezone it was in was lost. When doctrine then fetched the value, it used `DateTime::createFromFormat(...)` to create a `DateTime` for me. The problem is that since the timezone wasn't saved anywhere, it assumed that it was a Swedish date, and thus it removed two hours.

I believe that the correct way of doing it is to store the dates in the db as UTC. Then it will always work no matter what the default timezone is, even if I later decide to change it.

`date_default_timezone_set('UTC')` is not the answer. If I use it, I need to make sure that every `DateTime` that I pass to doctrine always has the timezone set to `UTC`. Since the `DateTime` can come from any number of sources (e.g. third party library) it could easily introduce hard to detect bugs. It will also output every date in the UTC timezone which may not be what I want if I'm developing a localised site (e.g. small page for a local Swedish business).



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

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





[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-471] when persisting objects to Doctrine2 and one of the tables are named the same as a MySQL reserved word Created: 24/Mar/13  Updated: 24/Mar/13  Resolved: 24/Mar/13

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

Type: Improvement Priority: Minor
Reporter: Per-Øivin Berg Andersen Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

MySQL on Ubuntu



 Description   

I am not sure this is a correct posting to your issue tracker, as I am a beginner at development, at least in the sense of doctrine.

I have an entity named Trigger in my Symfony2 project. I had set the table name to be "trigger", and this did not work. However, the entities were created without any problems, I first discovered the problem when attempting to persist a Trigger entity. The solution was to rename the table to "mtrigger" or something else, but I think the error message could be better somehow. Now it throws an exception with the MySQL error, which only says there's an error in the syntax, and to check the manual. The manual is quite huge and it was a horror for me before I started thinking in the field of reserved words.

Note that this is just a proposal to an improvement. It might be that it is hard to implement it for you. In that case, please just close the issue.



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

Doctrine 2 ORM allows you to define "naming strategies" and/or to quote the table names with mysql-style ticks that get automatically quoted, like:

/** @ORM\Table(name="`foo`") */




[DBAL-353] doctrine:schema:update doesn't understand it doesn't need to run again Created: 25/Sep/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Minor
Reporter: Mark A. Hershberger Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

doctrine:schema:update keeps thinking there is more to do:

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL
$ php app/console doctrine:schema:update --force   
Updating database schema...
Database schema updated successfully! "2" queries were executed
$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL


 Comments   
Comment by Christophe Coevoet [ 25/Sep/12 ]

Can you paste your ORM mapping for these fields ?

Comment by John Robeson [ 01/Nov/12 ]

I had the same problem. I used doctrine:mapping:import
to bootstrap some entities. It generated my
session entity primary key with a GeneratedValue strategy of
IDENTITY when it should have been NONE.

This sounds like the same problem with the string key
and incorrect GeneratedValue strategy.

PS: I ran into that doctrine:mapping:import issue
perhaps a year ago, when i first started playing with doctrine.
I do not know if it still persists.





[DBAL-358] This issue should be removed. Wrong merge on github. Created: 04/Oct/12  Updated: 03/Dec/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Trivial
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue should be removed. Wrong merge on github.



 Comments   
Comment by Benjamin Eberlei [ 04/Oct/12 ]

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

Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DBAL-814] [GH-528] Applying patch suggested by @guilhermeblanco for SQLite's auto-inc integer PKs Created: 14/Feb/14  Updated: 14/Feb/14  Resolved: 14/Feb/14

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

Type: Bug 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 Ocramius:

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

Message:

See symfony/symfony#10238

Ping @guilhermeblanco



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

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

Comment by Marco Pivetta [ 14/Feb/14 ]

https://github.com/doctrine/dbal/commit/da43b765e96ca8a80202fa5e2e67657e0ce61587





[DBAL-633] MSSQL False Created: 15/Oct/13  Updated: 26/Oct/13  Resolved: 26/Oct/13

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

Type: Bug Priority: Blocker
Reporter: Steven Masala Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

Hi there,

Migrations with MSSQL

protected $myfield = false;

DIFF ->

$this->addSql("ALTER TABLE dec_user ADD complete_render BIT NOT NULL");


DEFAULT 0 is missing here


according to stof

The generated statements are coming from the DBAL schema comparator, comparing the DB schema to the schema expected by the ORM.



 Comments   
Comment by Benjamin Eberlei [ 26/Oct/13 ]

Doctrine only generates default clauses if you use:

@Column(options={"default": "0"})

Not by looking at the default value of a field.





[DBAL-513] downloading from github Created: 12/May/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

Type: Bug Priority: Blocker
Reporter: Maarten Bogaert Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

https://api.github.com/repos/doctrine/dbal/zipball/2.3.4:

500: Internal Server Error



 Comments   
Comment by Maarten Bogaert [ 12/May/13 ]

ok never mind, after a while the problem resolved itself and the zipball can be downloaded again





[DBAL-496] "Undefined index" errors when using prepared statements Created: 16/Apr/13  Updated: 08/Sep/13  Resolved: 20/Apr/13

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

Type: Bug Priority: Blocker
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Since a few days we are seeing errors like this in the Jackalope Doctrine DBAL test suite when using prepared statements:
https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6350278#L117



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

First failure I can see is at https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6347501 - is there any other relevant failure before that one?

Comment by Marco Pivetta [ 16/Apr/13 ]

The notice is thrown in in

Doctrine\DBAL\SQLParserUtils::expandListParameters

Can be reproduced with parameters:

$query:

UPDATE phpcr_nodes SET sort_order = CASE CONCAT(
          namespace,
          (CASE namespace WHEN '' THEN '' ELSE ':' END),
          local_name
        ) WHEN :name0 THEN :order0 WHEN :name1 THEN :order1 WHEN :name2 THEN :order2 WHEN :name3 THEN :order3 WHEN :name4 THEN :order4 ELSE sort_order END WHERE parent = :absPath

$params:

array(
    ':absPath' => '/topic',
    ':name0' => 'page3',
    ':order0' => 0,
    ':name1' => 'page1',
    ':order1' => 1,
    ':name2' => 'page2',
    ':order2' => 2,
    ':name3' => 'page3',
    ':order3' => 3,
    ':name4' => 'page4',
    ':order4' => 4,
)

$types:

array()
Comment by David Buchmann [ 17/Apr/13 ]

are we doing something wrong or is this a regression in dbal?

should we for now force an older version of doctrine-dbal? (this would be annyoing however, as we would run into version conflicts with doctrine-commons then i think)

Comment by Daniel Leech [ 17/Apr/13 ]

Seems this is caused by: https://github.com/doctrine/dbal/commit/64647f9e55749147b738cdba9378fa0401fadcbf

Comment by Fabio B. Silva [ 18/Apr/13 ]

I think the problem here is the ':' on the parameter key, which i'm not sure if are suported for DBAL.
Before #DBAL-488 it does not apply 'SQLParserUtils::expandListParameters' for parameters without types.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Reverted in master and 2.3

Comment by Fabio B. Silva [ 20/Apr/13 ]

Benjamin, Not sure if we should consider this one related to #DBAL-488.
It just show us another unsupported/unexpected behavior.

Actually, it will keep failing with any parameter key starting with ':' when types are given.

For instance :

$query:

SELECT * FROM foo WHERE bar = :bar

$params:

array(':bar'=>'Some String')

$types:

array(':bar'=>\PDO::PARAM_STR)
Comment by Lars Strojny [ 21/Apr/13 ]

Here is a successor for the fix from PR 301, @Fabio, could you test that with your code base: https://github.com/doctrine/dbal/pull/309





[DBAL-402] Fatal error: Uncaught exception Created: 29/Dec/12  Updated: 25/Jun/13  Resolved: 25/Jun/13

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

Type: Bug Priority: Blocker
Reporter: Ruslan Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: dql, oracle


 Description   
Fatal error: Uncaught exception 'Doctrine\DBAL\Driver\OCI8\OCI8Exception' with message 'ORA-00904: "T0"."ID": invalid identifier' in /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php on line 28 Doctrine\DBAL\Driver\OCI8\OCI8Exception: ORA-00904: "T0"."ID": invalid identifier in /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php on line 28

Call Stack: 0.0002 665368
1. {main}() /var/www/doctrine/doctrine/tools/sandbox/index.php:0 0.3389 6023864
2. Doctrine\ORM\EntityManager->find() /var/www/doctrine/doctrine/tools/sandbox/index.php:71 0.3514 8264024
3. Doctrine\ORM\Persisters\BasicEntityPersister->load() /var/www/doctrine/doctrine/lib/Doctrine/ORM/EntityManager.php:444 0.3521 8413576 
4. Doctrine\DBAL\Connection->executeQuery() /var/www/doctrine/doctrine/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:725 0.3532 8625920
5. Doctrine\DBAL\Driver\OCI8\OCI8Statement->execute() /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Connection.php:635 Variables in local scope (#5): $hasZeroIndex = *uninitialized* $key = *uninitialized* $params = NULL $ret = FALSE $val = *uninitialized* 


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

Format code sample

Comment by Benjamin Eberlei [ 04/Apr/13 ]

What is wrong here? The error alone is not very helpful

Comment by Benjamin Eberlei [ 25/Jun/13 ]

No feedback given.





[DBAL-207] RemoveNamespacedAssets: Foreign Key removing does not work correctly Created: 22/Jan/12  Updated: 22/Jan/12  Resolved: 22/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2-RC1/RC2
Fix Version/s: 2.2.0-RC3, 2.2
Security Level: All

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


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

Fixed.





[DBAL-35] PDO_Sqlsrv bug in _constructPdoDsn() Created: 21/Jul/10  Updated: 31/Aug/10  Resolved: 31/Aug/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA2
Fix Version/s: 2.0.0-BETA4

Type: Bug Priority: Blocker
Reporter: Bostjan Oblak Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

Windows 7, Zend Server CE, Sql Server driver for PHP v2



 Description   

When connection to mssql server with pdo_sqlsrv driver you get:

 
[PDOException]
SQLSTATE[IMSSP]: The DSN string ended unexpectedly.

Sample $connectionOptions:

$connectionOptions = array(
    'dbname' => 'AdventureWorks',
    'user' => 'sa',
    'password' => 'sa_password',
    'host' => 'local',
    'driver' => 'pdo_sqlsrv'
);

Error is in Doctrine\DBAL\Driver\PDOSqlsrv\Driver in function _constructPdoDsn(array $params).
On line 53 dsn starts with

$dsn = 'sqlsrv:(';

instead of

$dsn = 'sqlsrv:server=(';

as written in offical Microsoft help which come with SQL Server Driver For PHP v2.



 Comments   
Comment by Benjamin Eberlei [ 21/Jul/10 ]

@Juozas can you evaluate this and possibly apply a fix?

Comment by Benjamin Eberlei [ 31/Aug/10 ]

Fixed





[DBAL-36] Database selection with DSN Created: 21/Jul/10  Updated: 08/Sep/10  Resolved: 08/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Bostjan Oblak Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Windows, Sql Server 2008, Sql server drivers for PHP v2



 Description   

When construstring DSN in Doctrine\DBAL\Driver\PDOSqlsrv\Driver it should add selection of database in DSN.

So for example DSN will look like:

$dsn ="sqlsrv:Server=(local) ; Database = AdventureWorks "; 

As writen in chm manual which come with Sql server drivers for PHP v2



 Comments   
Comment by Bostjan Oblak [ 08/Sep/10 ]

I changed this Issue to Bug and give it priority of blocker, since with final relase of Sql Server Driver 2 for PHP it's not working correctly.

Solution can be found on my blog: http://bostjan.muha.cc/2010/08/doctrine-2-mssql/

Comment by Benjamin Eberlei [ 08/Sep/10 ]

This was fixed in Beta4, but will probably be changed again for the next testrelease because of DBAL-49.





[DBAL-261] MasterSlaveConnection fails to load ConnectionEventArgs Created: 24/Apr/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

Type: Bug Priority: Blocker
Reporter: Raymond Burgess Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Incorrect class referenced at line 164 of Doctrine\DBAL\Connection\MasterSlaveConnection.php:

$eventArgs = new Event\ConnectionEventArgs($this);

Current namespace is Doctrine\DBAL\Connection so class loader fails when looking for Doctrine\DBAL\Connection\Event\ConnectionEventArgs

Work around is to add Doctrine\DBAL\Event\ConnectionEventArgs to use directive and change line to:

$eventArgs = new ConnectionEventArgs($this);






[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-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-1039] [GH-721] Add @return type hint Created: 07/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

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


 Description   

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

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

Message:



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

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





[DBAL-559] SQL Server Platform error on LOCK MODE in cases of inheritance Created: 17/Jul/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

Type: Bug Priority: Critical
Reporter: Fryderyk Benigni Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: sqlserver
Environment:

Windows Server, SQL Server 2008


Issue Links:
Duplicate
duplicates DDC-1624 Locking CTI doesnt work on SQL Server Resolved

 Description   

Whenever an inheritance is implemented the SQL Server Platform add a Lock Mode at the end of the query while for example on SQL Server 2008 it should add a lock on each joined object.

Current implementation of appendLockHint:

/**
 * {@inheritDoc}
 */
public function appendLockHint($fromClause, $lockMode)
{
    switch ($lockMode) {
        case LockMode::NONE:
            $lockClause = ' WITH (NOLOCK)';
            break;
        case LockMode::PESSIMISTIC_READ:
            $lockClause = ' WITH (HOLDLOCK, ROWLOCK)';
            break;
        case LockMode::PESSIMISTIC_WRITE:
            $lockClause = ' WITH (UPDLOCK, ROWLOCK)';
            break;
        default:
            $lockClause = '';
    }

    return $fromClause . $lockClause;
}

If the lock mode is added on each object the format of the query would be correct.



 Comments   
Comment by Benjamin Eberlei [ 08/Sep/13 ]

This is a known bug, see DDC-1624





[DBAL-434] Incorrect type mapping on Oracle Platform Created: 30/Jan/13  Updated: 17/Feb/13  Resolved: 30/Jan/13

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

Type: Bug Priority: Critical
Reporter: Damián Nohales Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

Oracle 10g on Windows, using Doctrine 2 with Symfony2



 Description   

Hello,

I'm noticed a strange behaviour when I executed a migration for my Oracle database. Doctrine detects changes on all date columns, generating queries like:

ALTER TABLE the_table MODIFY (the_date DATE DEFAULT NULL);

even if the entity property was not modified. Check in out the Doctrine 2 source code I've detected that Doctrine map the DATE Oracle columns as datetime type, but entity date property are mapped as date (as it should be), so Doctrine believes that entity property and column type are different and generate the alter query.

I found the problem on the method Doctrine\DBAL\Platforms\OraclePlatform::initializeDoctrineTypeMappings, when it say 'date' => 'datetime' should say 'date' => 'date', that fix the migration problem and does not break my application.

Was a typo?

Thanks!



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

The problem is that Oracle has a "DATE" type, which is actually a DATETIME. That is why we map it to Doctrine's Datetime type.

As a workaround, you can set this information yourself using:

$conn->getDatabasePlatform()->registerDoctrineTypeMapping('date', 'date');

Be aware this is a global change for all columns. If you map DateTimes to a TIMESTAMP field you are good to go though.

Comment by John Kary [ 17/Feb/13 ]

I ran into this same issue with the default OraclePlatform configuration. I was trying to run doctrine:schema:update --force from the Symfony2 Console on my Oracle database, and ALTER statements were generated for some DATE columns that were fully up to date when looking at the actual table.

But the major issue I ran into was these unnecessary ALTER statements were for DATE columns with NOT NULL constraints, resulting in a query like ALTER TABLE your_table MODIFY (created_at_date DATE NOT NULL); Yet when running this query, Oracle throws an error: ORA-01442: column to be modified to NOT NULL is already NOT NULL. So I could no longer use doctrine:schema:update to update my schema during development against Oracle.

While technically correct, Oracle DATE types actually store time data in addition to date data, I don't agree that this should be considered Doctrine's default behavior.

I believe Oracle DATE columns should be date-only (e.g. Day, Month, Year) and time data should be disregarded. All other drivers except SQLServer map "date" fields to Doctrine's "date" type. I would rather see someone wanting to store time data with their DATE field need to make the suggested change, instead of the other way around:

$conn->getDatabasePlatform()->registerDoctrineTypeMapping('date', 'datetime');

Oracle 11g Release 1 DATE type docs: http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#i1847)

Comment by Benjamin Eberlei [ 17/Feb/13 ]

Well the other thing is, that we cannot change this for BC reasons.

We could introduce a new platform that solves this issue though.





[DBAL-228] OCI8Statement' fetchAll method can not do with PDO::FETCH_BOTH Created: 02/Mar/12  Updated: 14/Mar/12  Resolved: 14/Mar/12

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

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


 Description   

/**

  • {@inheritdoc}

    */

private static $fetchStyleMap = array(
PDO::FETCH_BOTH => OCI_BOTH,
PDO::FETCH_ASSOC => OCI_ASSOC,
PDO::FETCH_NUM => OCI_NUM
);

public function fetchAll($fetchStyle = PDO::FETCH_BOTH)
{
if ( ! isset(self::$fetchStyleMap[$fetchStyle]))

{ throw new \InvalidArgumentException("Invalid fetch style: " . $fetchStyle); }

$result = array();
oci_fetch_all($this->_sth, $result, 0, -1,
self::$fetchStyleMap[$fetchStyle] | OCI_RETURN_NULLS | OCI_FETCHSTATEMENT_BY_ROW | OCI_RETURN_LOBS);

return $result;
}

oci_fetch_all method can only surport

  • OCI_NUM
  • OCI_ASSOC

in $fetchStyleMap, OCI_BOTH is included!!!!



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/12 ]

Fixed





[DBAL-168] orm:schema-tool:update will fail if if public scheme has a domains table (PostgreSQL) Created: 22/Sep/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Bug Priority: Critical
Reporter: Martin Prebio Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

If I create a table 'domains' in the default scheme and execute the update procedure of the schema tool, it will throw a PDOException (SQLSTATE[21000]: Cardinality violation: 7 ERROR: more than one row returned by a subquery used as an expression)

I've traced the error to the following statement, which is created by Doctrine\DBAL\Platforms\PostgreSqlPlatform->getListTableForeignKeysSQL():

SELECT r.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 c.relname = 'domains'
                        AND n.oid = c.relnamespace
                  )
                  AND r.contype = 'f'

This returns two oids because there are two relations with the name domains. One is my table and the other is a view in the information_scheme scheme.

The same problem should occur with the other information_scheme relations.



 Comments   
Comment by Benjamin Eberlei [ 30/Oct/11 ]

Hm the domains entry doesnt seems to pop up for me in pgadmin when executing your query. Can you help me a bit with details on how to reproduce this?

Comment by Martin Prebio [ 31/Oct/11 ]

montbook:~ postgres$ createdb -E UTF8 -T template0 -l de_AT.UTF-8 foo
montbook:~ postgres$ psql foo
foo=# create table domains (id int8 not null);

Now I have a table domains in the default schema and a domains table in the information_schema schema which is created and maintained by postgres. Now executing the query above will produce the mentioned exception.

It was necessary to create a table in the fresh database to create the information_schema. It is a meta schema from where you can select information of the database and it is afaik a sql standard (also mysql has it but as a seperate database).

pgAdmin may hide this schema (and the pg_catalog): http://www.mail-archive.com/pgadmin-support@postgresql.org/msg09332.html

Comment by Benjamin Eberlei [ 14/Nov/11 ]

Fixed and merged into 2.1.x





[DBAL-129] Doctrine\ORM\Mapping\ClassMetadataInfo does not properly handle identifier quoting Created: 10/Jun/11  Updated: 17/Jun/11  Resolved: 15/Jun/11

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

Type: Bug Priority: Critical
Reporter: Patrick Schwisow Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 1
Labels: None


 Description   

Several methods in Doctrine\ORM\Mapping\ClassMetadataInfo assume that table names and field names may be quoted. In all places, logic assumes that the quote character will always be ` (backtick). There seems to be no way to properly quote table names with [] (square brackets) when working with SQL Server databases.



 Comments   
Comment by Benjamin Eberlei [ 11/Jun/11 ]

Just use `foo` as quotes, its just an abstract concept, doctrine will translate that to [foo] in MsSQL.

Comment by Patrick Schwisow [ 13/Jun/11 ]

I don't see how that would work. It appears that DBAL\Platforms\AbstractPlatform::quoteIdentifier assumes that the opening and closing quotes are the same. In the case of MS SQL, it appears to use the double quote, not square brackets.

Comment by Benjamin Eberlei [ 15/Jun/11 ]

Assigned to Juokaz

Comment by Benjamin Eberlei [ 15/Jun/11 ]

Fixed





[DBAL-114] MsSqlPlatform - getListTablesSQL() get's sysdiagrams table Created: 26/Apr/11  Updated: 29/Aug/11  Resolved: 29/Aug/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0.4
Fix Version/s: 2.1.2, 2.2

Type: Bug Priority: Critical
Reporter: Bostjan Oblak Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 1
Labels: None
Environment:

Windows 7, PHP 5.3.5, MSSQL 2008



 Description   

getListTablesSQL() function in MsSqlPlatform.php list all tables in database.

If you have saved Database Diagrams it returns "sysdiagrams" table too.
This table have field "name" with type "sysname" which have no mapping.

If you run orm:validate-schema you get:
[Doctrine\DBAL\DBALException]
Unknown database type sysname requested, Doctrine\DBAL\Platforms\MsSqlPlatform may not support it.

Best solution is that when getting tables to ignore "sysdiagrams" tables.



 Comments   
Comment by Bostjan Oblak [ 26/Apr/11 ]

One solution is to just add "AND name != 'sysdiagrams' " to sql statement

Comment by Benjamin Eberlei [ 30/Apr/11 ]

Assigned to Jouzas

Comment by Yaroslav Zenin [ 07/Jul/11 ]

Why it is not fixed yet? The solution is so easy. Please add to repository. Because on every release I should change it manually

Comment by Benjamin Eberlei [ 29/Aug/11 ]

Fixed





[DBAL-111] MySQL Driver possibly subject to sql injections with PDO::quote() Created: 18/Apr/11  Updated: 14/May/11  Resolved: 14/May/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA2, 2.0.0-BETA3, 2.0.0-BETA4, 2.0.0-RC1-RC3, 2.0-RC4, 2.0-RC5, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.1
Fix Version/s: 2.0.4, 2.0.5, 2.1

Type: Bug Priority: Critical
Reporter: Anthony Ferrara Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

MySQL Drivers



 Description   

Prior to 5.3.6, the MySQL PDO driver ignored the character set parameter to options. Due to MySQL's C api (and MySQLND), this is required for the proper function of mysql_real_escape_string() (the C API call). Since PDO uses the mres() C call for PDO::quote(), this means that the quoted string does not take into account the connection character set.

Starting with 5.3.6, that was fixed. So now if you pass the proper character set to PDO via driver options, sql injection is impossible while using the PDO::quote() api call.

PDO proof of concept
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK;';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
            FROM INFORMATION_SCHEMA.TABLES
            WHERE TABLE_NAME LIKE ".$pdo->quote($string)." LIMIT 1;";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());

Expected Result: `int(0)`.
Actual Result: `int(1)`.

There are 2 issues to fix. First, the documentation does not indicate that you can pass the `charset` option to the MySQL Driver. This should be fixed so that users are given the proper option to set character sets.

Secondly, `Connection::setCharset()` should be modified for MySQL to throw an exception, since the character set is only safely setable using the DSN with PDO. This is a limitation of the driver and could be asked as a feature request for the PHP core. Either that, or a big warning should be put on the documentation of the API to indicate the unsafe character set change



 Comments   
Comment by Anthony Ferrara [ 19/Apr/11 ]

Note: issued same bug report for Doctrine1 as it's also affected: http://www.doctrine-project.org/jira/browse/DC-998

Comment by Anthony Ferrara [ 29/Apr/11 ]

Also note that prepared statements in PDO will suffer the same bug since PDO always emulates prepared statements for the mysql driver (even though it fully supports them in the source). See: http://bugs.php.net/bug.php?id=54638

Comment by Benjamin Eberlei [ 14/May/11 ]

Fixed, updated the docs





[DBAL-80] Connection::_bindTypedValues() error when $types[0] is null Created: 01/Jan/11  Updated: 01/Jan/11  Resolved: 01/Jan/11

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

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


 Description   

When $types[0] = null (default) then _bindTypedValues starts with the wrong offset and binds the wrong types against the wrong params.



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

Fixed





[DBAL-54] Incorrect sequence dropping in PostgreSQL Created: 21/Sep/10  Updated: 09/Oct/12  Resolved: 23/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.2.2
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Critical
Reporter: Tomasz Jędrzejewski Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

postgresql 8.4.3, Arch Linux 64-bit



 Description   

Currently, DBAL drops the PostgreSQL sequences using the query:

DROP SEQUENCE sequencename

While it is quite correct at the first look, it fails, if the sequence is actually used by a table. Because Doctrine 2 ORM tries to drop the sequences before the tables, it makes impossible to drop a database schema in PostgreSQL due to the following exception:


$ php53 doctrine.php orm:schema-tool:drop
Dropping database schema...
PDOException
SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence admins_id_seq because other objects depend on it
DETAIL: default for table admins column id depends on sequence admins_id_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.
/.../Libs/Doctrine/DBAL/Connection.php
Line 570
Trace:
0. PDO::query on line 570
1. Doctrine\DBAL\Connection::executeQuery on line 484
2. Doctrine\ORM\Tools\SchemaTool::dropSchema on line 78
3. Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand::executeSchemaCommand on line 59
4. Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand::execute on line 159
5. Symfony\Component\Console\Command\Command::run on line 205
6. Symfony\Component\Console\Application::doRun on line 117
7. Symfony\Component\Console\Application::run on line 7


A solution is simply to add the "CASCADE" keyword at the end of the query.

Although I encountered this problem on DBAL 2.0-beta4, I checked the most up-to-date code on Git, and the problem is still present there.



 Comments   
Comment by Benjamin Eberlei [ 21/Sep/10 ]

Would it help to drop sequences after tables? If then i would just move the code blocks.

Comment by Tomasz Jędrzejewski [ 21/Sep/10 ]

In this particular case - yes, it would help. But consider that different database engines may have different dependencies between schema elements and be more or less restrictive, so they may require different order of code blocks. I'd recommend to make a bit deeper investigation here in order not to cause potential problems with other database engines.

Comment by Benjamin Eberlei [ 23/Sep/10 ]

Fixed

Comment by Jon Wadsworth [ 20/Jun/12 ]

This issue is happening again with Doctrine 2.2.2 on Postgres 9.1.3. when trying to drio a database I get this message even with --full-database

> php doctrine.php orm:schema-tool:drop --force --full-database
Dropping database schema...

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

I would love to help diagnose, just let me know what you need and I will be more than happy to help.

Comment by Jon Wadsworth [ 09/Oct/12 ]

I forgot to update this for anyone else who might have had my problem. The issue was solved for me when I was reviewing some models. The project was originally intended for MySQL and Generated Value Strategy was not set to Auto. Upon changing it to auto, everything worked correctly.





[DBAL-52] Schema tools will alter tables with custom column definitions forever Created: 15/Sep/10  Updated: 15/Sep/10  Resolved: 15/Sep/10

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

Type: Bug Priority: Critical
Reporter: Lars Strojny Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None
Environment:

MySQL 5.1, PDO MySQL



 Description   

When using custom column definition, schema tool will execute the same update statements over and over. It looks like schema tool can't find out yet, if the custom column definition has already been applied.
As MySQL does full table rebuilds quite often (sometimes for no or at least debatable reasons), this makes the schema tool for large migrations quite hard to use in a production system deployment scenario.



 Comments   
Comment by Benjamin Eberlei [ 15/Sep/10 ]

Yes this is a known issue, i plan to fix this with DDC-42, however it will take until 2.1 i guess. It annoys me too

Maybe we should also add a note to the manual, schema-tool incremental update is a development tool and should not be used on the production server.





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

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

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


 Description   

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

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

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

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

I am using current git clone and PgSQL 8.4.



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

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

Comment by Benjamin Eberlei [ 09/Sep/10 ]

i'll look into it.

Comment by Benjamin Eberlei [ 11/Sep/10 ]

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

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

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

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

Comment by Benjamin Eberlei [ 11/Sep/10 ]

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

cd lib/vendor/doctrine-dbal
git checkout master

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





[DBAL-244] Shema Tool is not working after DBAL-177 for postgresql (mysql working like before) Created: 25/Mar/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

Type: Bug Priority: Critical
Reporter: Margus Sipria Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 10.10, Zend Server 5.5.0 with PHP 5.3.8



 Description   

After trying to upgrade 2.2.0 i found that schema tool wasn't working, so I switched back to 2.1.6, same thing with 2.2.1 and no bug report, so this is wats going on.

./doctrine orm:schema-tool:update --dump-sql # this will show full create table for schema even if tables are all ready there.

After git bisectin Doctrine ORM project i found that commit ea5108ea0f35fc0f7ed3a740995a590926045c6e wast to blame, but that was only submodule update so made bisect for Doctrine DBAL:

537de7ea6a34edbcc40bc6ca92e0a3f816b59330 .. 4410e4cec20b0f1f209578320e5b7d111e90c2a0 founding that 1ae87bf3e3ba93cb579a2a092b06b5a09b316542 was the problem.

[margus@laptop doctrine-dbal ((4410e4c...))]$ git reset --hard 1ae87bf3e3ba93cb579a2a092b06b5a09b316542
HEAD is now at 1ae87bf DBAL-177 - Make sure schema.table syntax is supported in Assets for quoted assets
[margus@laptop doctrine-dbal ((1ae87bf...))]$ git submodule update --recursive
Submodule path 'lib/vendor/doctrine-common': checked out 'd6e4c8b22af9800db4fd9d679ce98538da028168'

    1. shema tool printing full schema

[margus@laptop doctrine-dbal ((1ae87bf...))]$ git reset --hard HEAD^1
HEAD is now at bb84496 DBAL-144 - Dont throw exception when no primary key exists
[margus@laptop doctrine-dbal ((bb84496...))]$ git submodule update --recursive

    1. works fine

[margus@laptop build (master)]$ ./doctrine orm:schema-tool:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.

with commit 1ae87bf3e3ba93cb579a2a092b06b5a09b316542 schema starts with 3 NULL lines, and then schema, with 2.2.0, extra "NULL" lines aren't there anymore.

Using MySQL there isn't any problem, but with PostgreSQL (i have 8.4.11) this issue appears.



 Comments   
Comment by Benjamin Eberlei [ 30/Mar/12 ]

Increase priority, will be fixed this weekend and in the next bugifx release

Comment by Benjamin Eberlei [ 30/Mar/12 ]

Are you using Postgresql Schema? Can you provide some information about your database tables? I need some more information to try reproducing this.

Comment by Nikolai Spassoff [ 03/May/12 ]

I'm experiencing the same issue.
I looked at the mentioned commit and found out that the SQL query in getSchemaNames() does not return any namespaces.
After some research I came with the following query to list all non-system namespaces in Postgres:

SELECT nspname as schema_name FROM pg_namespace WHERE nspname !~ '^pg_.*' and nspname != 'information_schema'

This fixed the issue for me and the schema-tool works again.

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed, but couldn't verify as the previous statement worked for me.





[DBAL-44] nullable is not working for all datatypes Created: 30/Aug/10  Updated: 16/May/14  Resolved: 30/Aug/10

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

Type: Bug Priority: Critical
Reporter: Daniel Freudenberger Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Attachments: Text File nullable.patch    
Issue Links:
Reference
is referenced by DDC-1045 Schema-tool update missbehavior: Not ... Closed

 Description   

The nullable=true annotation is ignored from at least following Types:

  • SmallIntType
  • DecimalType
  • BooleanType (not sure if nullable makes sense here)


 Comments   
Comment by Roman S. Borschel [ 30/Aug/10 ]

This looks like it has been fixed for a while already. See:

http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/SmallIntType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/BooleanType.php

Comment by Daniel Freudenberger [ 30/Aug/10 ]

I'll take a look at the master next time before submitting a bug report. Anyway I think it would be better to not fix bugs without an existing ticket for the fixed bug

Comment by Daniel Freudenberger [ 30/Aug/10 ]

has already been fixed





[DBAL-859] OraclePlatform: rownum should not be used directly in WHERE clausule Created: 12/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Oracle, All OSes.


Attachments: File OraclePlatform.php     File OraclePlatform_bugfix.php    

 Description   

At 90% of cases when we use ROWNUM in WHERE clause it will work correctly, but sometimes not. I noticed that that is why Doctrine sometimes works incorrect.
Source:
http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html

Quote:
"That is why a query in the following form is almost certainly an error:

select *
from emp
where ROWNUM <= 5
order by sal desc;
"

I prepared modified OraclePlatform.php with solution (attachment) - rownum is being compared after all operations.



 Comments   
Comment by Steve Müller [ 01/Apr/14 ]

Mariusz Jaskółka can you please provide an example where the current implementation fails? We have functional tests LIMIT queries in DBAL but they run fine on Oracle. I need more information to be able to reproduce this problem.

Comment by Marco Pivetta [ 26/Jun/14 ]

This issue is missing a valid test case - marking as incomplete.





[DBAL-863] [GH-564] [DBAL-630] Incorrect PostgreSQL boolean handling Created: 04/Apr/14  Updated: 30/Jun/14  Resolved: 27/Jun/14

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: boolean, dbal, orm, postgresql

Issue Links:
Reference
relates to DBAL-931 pgSql boolean conversion Resolved

 Description   

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

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

Message:

Working on PostgreSQL incorrect boolean handling when emulating prepared statements



 Comments   
Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

This PR is related to http://www.doctrine-project.org/jira/browse/DBAL-630

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

The only issue with this PR is that it breaks Doctrine2 ORM. I already have a patch for that too, but I'm not sure on how to proceed.

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

I'm not breaking ORM anymore.

Comment by Doctrine Bot [ 27/Jun/14 ]

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

Comment by Marco Pivetta [ 27/Jun/14 ]

Moved to PR https://github.com/doctrine/dbal/pull/625

Comment by Doctrine Bot [ 30/Jun/14 ]

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





[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-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-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-1068] Microsoft SQL Server issues with ANSI_NULLS=OFF Created: 09/Dec/14  Updated: 13/Dec/14  Resolved: 13/Dec/14

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

Type: Bug Priority: Critical
Reporter: man4red Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Microsoft SQL Server 2012 (11.0.5058)

zf2, doctrine2, skeletonApplication, + modules
zf-commons/zfc-base v0.1.2
zf-commons/zfc-user 1.2.1
zf-commons/zfc-user-doctrine-orm dev-master
bjyoungblood/bjy-authorize dev-master


Attachments: PNG File bug1.png     PNG File bug2.png    

 Description   

So here what I have (see my Environment for more details)

$modules = array(
    'Application', //skeleton
    'DoctrineModule',
    'DoctrineORMModule',
    'DoctrineDataFixtureModule',
    'ZfcBase',
    'ZfcUser',
    'ZfcUserDoctrineORM',
    'BjyAuthorize',
    'User', // Entity copied from BjyAuthorize vendor folder
);
//module/User/Entity/User.php (copied from vendor\bjyoungblood\bjy-authorize\data\User.php.dist)
...
    /**
     * @var string
     * @ORM\Column(type="string", length=255, unique=true, nullable=true)
     */
    protected $username;
...
./vendor/doctrine/doctrine-module/bin/doctrine-module orm:schema-tool:create --dump-sql
CREATE TABLE [users] (id INT IDENTITY NOT NULL, username NVARCHAR(255), email NVARCHAR(255) NOT NULL, displayName NVARCHAR(50), password NVARCHAR(128) NOT NULL, state INT NOT NULL, PRIMARY KEY (id));
CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL;
...
and so on...

on create

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 Cannot create index. Object 'users' was created with the following SET options off: 'ANSI_NULLS'. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E06
77 ON [users] (username) WHERE username IS NOT NULL
....

Maybe this helps:

My database created in MSSQL and has default option ANSI_NULLS = OFF

see my options (bug1.png)

ok, changed it to ANSI_NULLS = ON according to documentation (but for now this sets OFF by default on create database)

got a new exception

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query noti
fications and/or XML data type methods and/or spatial index operations. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL

Then I copied to Microsoft SQL Management Studio code above.
No error!

Then I chcked off this checkbox in SQL Management Studio
(see bug2.png)

and SQL query now failed with almost the same error, but now in Management Studio!

Msg 1934, Level 16, State 1, Line 2
CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.

So it seems that problem starts when we set for username unique=true and using MSSQL that trying to create UNIQUE INDEX ... WHERE fieled IS NOT NULL

Some related topics:
ANSI_NULLS
CONCAT_NULL_YIELDS_NULL
ANSI_WARNINGS
ANSI_PADDING
Creating a unique constraint that ignores nulls in SQL Server

Going to move my project to MySQL if this bug are not my fault



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

This is nothing we can control in Doctrine. According to the documentation http://msdn.microsoft.com/en-us/library/ms189292.aspx there are some requirements server-side that have to be met in order for such unique constraints to work. You will have to configure your server properly.

Comment by man4red [ 12/Dec/14 ]

Yep, thx for answer, but according to the same documentation:

The ANSI_NULLS connection-level option must be set to ON when the CREATE TABLE or ALTER TABLE statement that defines the computed column is executed. The OBJECTPROPERTY function reports whether the option is on through the IsAnsiNullsOn property.

The connection on which the index is created, and all connections trying INSERT, UPDATE, or DELETE statements that will change values in the index, must have six SET options set to ON and one option set to OFF. The optimizer ignores an index on a computed column for any SELECT statement executed by a connection that does not have these same option settings.
The NUMERIC_ROUNDABORT option must be set to OFF, and the following options must be set to ON:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
Setting ANSI_WARNINGS to ON implicitly sets ARITHABORT to ON when the database compatibility level is set to 90 or higher.

So my fixtures are created without correct connection-level option

Am I wrong?

Comment by man4red [ 12/Dec/14 ]

I think that problem is still persist.
According to documentation connection must have some options (see http://msdn.microsoft.com/en-us/library/ms189292.aspx and my comment)

Propose to pay more attention to the problem.

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

Hmmm I suppose that there is something wrong with your setup/configuration then. I just tested this using DBAL + sqlsrv driver + SQL Server 2012 and it adds the unique index on a nullable column without problems. Not sure what's wrong with your client/server setup then. Also I don't see how one would set those settings in the connection handle...
Which database driver are you using? sqlsrv or pdo_sqlsrv?

Comment by man4red [ 12/Dec/14 ]

Sorry for bothering you/
Now I began to suspect that the case in the client
I'll test today booth setup on a diffirent clients

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

Nevermind
If there truly is a bug we'll fix that somehow but as this is really common core functionality and nobody complained so far I suppose it's really related to your environment. Please let me know if I can close the issue as soon as you have checked your env.
Thanks!

Comment by man4red [ 12/Dec/14 ]

Steve, it seems, that problem persist only with FreeTDS/dblib driver (my env). Probably sqlsrv driver does set this parameters automatically.
Unfortunately there is no other mssql drivers for linux, so situation is very strange. Maybe there is nobody using linux + mssql env? Crzy Also forced to move to pdo_mysql.

Untill dblib not supported for doctrine - we can mark this as invalid.
Thx for your help

Comment by man4red [ 12/Dec/14 ]

Am I right at conclusion that:
1. Linux users can use dblib+mssql and had this issues. To fix this they can set connection-level paramters somehow before ALTER TABLE by querying "SET ANSI_NULLS ON; SET ANSI_PADDING ON; ..." etc...
2. There is only windows users are able to use doctrine DBAL with mssql without any problems thru sqlsrv driver provided by microsoft?
it bothers me in some way

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

Hehe we could have saved a lot of time if you had mentioned earlier that your are using dblib driver
But nevermind. dblib is not supported by Doctrine as it is an experimental driver and quite buggy. Not even sure how you managed to get DBAL connecting through dblib without a custom driver implementation. Whatsoever, unfortunately you are right, there currently is no officially supported way of connecting with DBAL to a SQL Server using a linux client. And yes only Windows users can do that by using either pdo_sqlsrv or native sqlsrv drivers provided by M$
If you are not bound to a Microsoft SQL Server backend and can use an alternative such as MySQL or any other database vendor I would then advise you to do that. I highly discourage you to start messing with dblib and its bugs/incompatibilities. If you are really bound to SQL Server you'll have to let your PHP application run on a windows machine and utilize one of Microsoft's PHP drivers. Hope that helps for now...
Closing then...





[DBAL-865] [GH-565] fix lastInsertId typehint in SqlSrv Created: 12/Apr/14  Updated: 13/Apr/14  Resolved: 13/Apr/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 Tobion:

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

Message:

An LastInsertId|null is expected.



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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/32817aac490eeba4c39bd7670ec2f6182e496fc5





[DBAL-851] [GH-556] fix date format on oracle Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/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 Tobion:

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

Message:



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

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





[DBAL-852] [GH-557] fix date format on oracle Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/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 Tobion:

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

Message:

The expected format for DATE columns is `01-MAR-14`. See http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT413

It also works with `01-Mar-2014` as this PR uses.

We found the problem when trying something like

```
$this->oracleCon->executeQuery(
'SELECT * FROM table WHERE datefield > ?',
array(new \DateTime()),
array(Type::DATE)
);
```

which was raising an oracle error that the date could not be parsed.

The



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

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





[DBAL-845] [GH-550] Type specification Created: 22/Mar/14  Updated: 22/Mar/14  Resolved: 22/Mar/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


 Description   

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

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

Message:

To avoid warning when extend this class.



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

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

Comment by Marco Pivetta [ 22/Mar/14 ]

Won't be fixed in 2.x





[DBAL-847] [GH-552] Quote create update and delete methods Created: 25/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/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


 Description   

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

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

Message:

Add quote for field names.



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-838] [GH-544] ORACLE, (INSTANCE_NAME = XXXXX) Created: 18/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-841 [GH-547] Add the instancename paramet... Resolved

 Description   

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

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

Message:

Hello, first sorry for my English.
I need to put in the ORACLE Connection string to the parameter: (INSTANCE_NAME = XXXXX)

I was reading the source code at github and the latest version does not include this possibility in the method getEasyConnectString.

Could add to the next version an element in the array of parameters, eg $params['instance_name'] and concatenating that value to the Connection string?

Thank you, greetings
Facundo Panizza



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-836] [GH-543] Clauses LEFT OUTER JOIN and RIGHT OUTER JOIN Created: 13/Mar/14  Updated: 14/Mar/14  Resolved: 14/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Added methods for construction of clauses LEFT OUTER JOIN and RIGHT OUTER JOIN



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

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





[DBAL-841] [GH-547] Add the instancename parameter for oci8 driver Created: 19/Mar/14  Updated: 25/Mar/14  Resolved: 19/Mar/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:
Reference
relates to DBAL-838 [GH-544] ORACLE, (INSTANCE_NAME = XXXXX) Resolved

 Description   

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

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

Message:

We add the instancename parameter documentation for oci8 driver



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

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

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

Part of PR: https://github.com/doctrine/dbal/pull/544

Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-829] binding with PARAM_INT_ARRAY does not convert the values to integer Created: 04/Mar/14  Updated: 04/Mar/14  Resolved: 04/Mar/14

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

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


 Description   

When using PARAM_INT_ARRAY to bind values for 'in' clause
the resulting sql has quotes around the numbers

e.g. using query builder I have

$qb->setParameters(
array('id' => $pnums),
array('id' => Connection::PARAM_INT_ARRAY)
);

produces

"select .... from tableName where id in ('123','456','789')"

given that the array had numeric value as strings,
$ids = array('123','456','789');

but since we are specifying PARAM_INT_ARRAY, I think this should be taken care of by doctrine



 Comments   
Comment by Ananda Agrawal [ 04/Mar/14 ]

looks like PDO issue





[DBAL-832] [GH-541] Allow mysql spatial indexes Created: 06/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Allows spatial indexes via the SPATIAL flag.
http://dev.mysql.com/doc/refman/5.7/en/creating-spatial-indexes.html



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-823] [GH-534] [DBAL-813] Original PDOException is preserved Created: 23/Feb/14  Updated: 23/Feb/14  Resolved: 23/Feb/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

Issue Links:
Dependency
is required for DBAL-813 Original PDOException is dropped from... Resolved

 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DBAL-813



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

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

Comment by Marco Pivetta [ 23/Feb/14 ]

merged: https://github.com/doctrine/dbal/commit/646edacd87d5b9d201bf19aaf55ee0e4d5e470c2





[DBAL-815] Returning a wrong field type for Postgres Created: 18/Feb/14  Updated: 18/Feb/14  Resolved: 18/Feb/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: Odiel Leon Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-553 PostgreSQL JSON Type Resolved

 Description   

Trying to create a Postgres table widh a JSON field type I found a bug, the following code is not returning the right field type for this operation.

https://github.com/doctrine/dbal/blob/ca6a8dd20f3e8c1ad5fadaac8eac4547c081cf3b/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php#L864

It is returning TEXT instead of JSON.

Take in consideration that if a table was created before and an update is required in order to change the table structure errors will shown up, here an example.

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE mytable ALTER metadata TYPE JSON':

SQLSTATE[42804]: Datatype mismatch: 7 ERROR: column "metadata" cannot be cast automatically to type json
HINT: Specify a USING expression to perform the conversion.

[PDOException]
SQLSTATE[42804]: Datatype mismatch: 7 ERROR: column "metadata" cannot be cast automatically to type json
HINT: Specify a USING expression to perform the conversion.



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

Odiel Leon The JSON data type is only available in PostgreSQL version 9.2 and onwards. We added support for the native JSON data type in DBAL 2.5, which is not yet released. If you want to make use of the native JSON type you have to configure DBAL to use PostgreSQL92Platform.

Comment by Steve Müller [ 18/Feb/14 ]

Still for versions < 9.2 the TEXT type still should work. Unfortunately you did not provide enough information about what you are trying to achieve and in which context your mentioned errors occurr. But this is definitely not a bug in Doctrine.

Comment by Steve Müller [ 18/Feb/14 ]

Here is the PR where we implemented native JSON type support: https://github.com/doctrine/dbal/pull/469

Comment by Odiel Leon [ 18/Feb/14 ]

Yes sorry about that.

Basically I'm trying to create a JSON field type in a Postgres table, I'm using Postgres 9.3.

Trying to update my DB from the command line using Symfony2 commands, doctrine:update:schema, I always get a query updating the field to be TEXT, even if I force the command to run, it pops up again and again, not changing the field to be JSON type, here is the code for my entity:

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="mytable")
 */
class Mytable
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

	/**
	 * @var string
	 *
	 * @ORM\Column(name="signature", type="json_array")
	 */
	private $signature;

	/**
	 * @var int
	 *
	 * @ORM\Column(name="created_at", type="datetime")
	 */
	private $createdAt;


    /**
     * Get id
     *
	 * @codeCoverageIgnore
     * @return integer
     */
    public function getSignature()
    {
        return $this->id;
    }

	/**
	 * Sets the job id.
	 *
	 * @param $signature
	 * @return $this
	 */
	public function setSignature($signature)
    {
        $this->signature = $signature;

        return $this;
    }

	/**
	 * Sets the created at timestamp.
	 *
	 * @param int $timestamp
	 * @return $this
	 */
	public function setCreatedAt($timestamp)
	{
		$this->createdAt = $timestamp;

		return $this;
	}

	/**
	 * Returns the created at timestamp.
	 *
	 * @return int
	 */
	public function getCreatedAt()
	{
		return $this->createdAt;
	}

}
Comment by Steve Müller [ 18/Feb/14 ]

Yeah, as I said, native JSON types will be supported in DBAL 2.5. If you want to make immediate use of this, you have to upgrade your dependencies to use one of the Doctrine 2.5 beta versions or the current master. Also please note when doing this upgrade for DBAL only, this might break ORM compatibility unless you upgrade ORM to an according version, too.

Comment by Odiel Leon [ 18/Feb/14 ]

Ok, that sounds good, thanks for the explanation, would you be able to point me out a good ORM version compatible with it?

Comment by Steve Müller [ 18/Feb/14 ]

IMO you should use DBAL master and ORM master, which should be in sync at most. BUT!! We do not advice you to use it in production as we don't take responsibility for it being stable by now. ORM does not have a beta for 2.5 yet.





[DBAL-817] [GH-530] Skip empty config values Created: 19/Feb/14  Updated: 05/Mar/14  Resolved: 05/Mar/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 MaartenMortier:

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

Message:

We should skip empty values when building dsn, this allows us to define multiple config variables and keeping config template intact.



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

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





[DBAL-813] Original PDOException is dropped from previous property in wrapper Created: 14/Feb/14  Updated: 23/Feb/14  Resolved: 23/Feb/14

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

Type: Bug Priority: Major
Reporter: Filip Procházka Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Dependency
depends on DBAL-823 [GH-534] [DBAL-813] Original PDOExcep... Resolved

 Description   

https://github.com/doctrine/dbal/commit/262deeb122d4de1ad893c8a8c944b1c1926317cd#diff-276fe718ac0aa7fc20162d42ae4dc7b0R52

Is there any case when PDOException has it's own previous? I don't know of any. Even if it had one, it doesn't make sense because you're skipping one important!! piece in chain of exceptions that cause each other

Do you agree that the ->getPrevious() is wrong and should be removed? Should I send a pullrequest?



 Comments   
Comment by Steve Müller [ 23/Feb/14 ]

After having added the missing information from the wrapped \PDOException to Doctrine\DBAL\Driver\PDOException in commit:
https://github.com/doctrine/dbal/blob/b362492900bc59800441e0d9922736fc55bf8c41/lib/Doctrine/DBAL/Driver/PDOException.php#L54-L55
all information from \PDOException should be retrievable from the Doctrine\DBAL\Driver\PDOException wrapper now. Therefore there should be no change in behaviour in existing applications.
Filip Procházka Are you okay with the solution? Can this ticket be closed?

Comment by Filip Procházka [ 23/Feb/14 ]

I disagree, first of all you're dropping a stack trace of that exception and replacing it with other from higher level, it may not be all that important, but all best practises say that you should always pass the exception to `$previous`.

There is zero disadvantages when keeping the exception in the chain. The few kilobytes of memory saved means nothing in comparision to backwards compatibility (which was broken without any real benefit).

Comment by Marco Pivetta [ 23/Feb/14 ]

I agree that the original PDOException should be passed in as $previous, since PDOExceptions themselves may or may not have a non-null getPrevious() result.

Filip Procházka can you provide a pull request for that?

Comment by Filip Procházka [ 23/Feb/14 ]

Yes I can! There you go https://github.com/doctrine/dbal/pull/534 let me know if it needs any adjustments.

Comment by Doctrine Bot [ 23/Feb/14 ]

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

Comment by Marco Pivetta [ 23/Feb/14 ]

merged: https://github.com/doctrine/dbal/commit/646edacd87d5b9d201bf19aaf55ee0e4d5e470c2

Comment by Filip Procházka [ 23/Feb/14 ]

Thank you very much!





[DBAL-809] Decimal type: not convert to double variable type Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Vitaliy Zhuk Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

Hi.

The doctrine DBAL type "decimal" not convert value to "double" variable type in PHP. And if use events for control changes set, we have a changes for field.

For example:

/** Entity class **/
/** @ORM\Column(name="field", type="decimal")
private $field;

/** Create entity **/
$entity = new MyEntity();
$entity->setField(1);
$em->persist($entity);
$em->flush($entity);

/** Load entity **/
$entity = $em->field('MyEntity', 1);
var_dump($entity->getField()); // Then we have a string type
$entity->setField(1); // Set a integer type

Listener (onFlush):

$em = $event->getEntityManager();
$uow = $em->getUnitOfWork();

$entity = $event->getEntity();
$changes = $uow->getEntityChangeSet($entity);

var_dump($changes); // Changes exists, because variable type not equals

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php#L52



 Comments   
Comment by Vitaliy Zhuk [ 09/Feb/14 ]

Sorry, i not seen the attention section in docs: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#decimal





[DBAL-803] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Bug Priority: Major
Reporter: Stefano Kowalke Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: mysql, querybuilder,
Environment:

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
duplicates DBAL-804 [GH-523] SQLSTATE[HY093]: Invalid par... Resolved

 Description   

This can be closed. I moved the description to http://www.doctrine-project.org/jira/browse/DBAL-804






[DBAL-799] [GH-521] Fix Connection Interface Created: 29/Jan/14  Updated: 29/Jan/14  Resolved: 29/Jan/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: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-794 [GH-517] Fix method signature in Doct... Resolved

 Description   

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

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

Message:

PDOConnection passes a second variable into prepare.
The Interface should support it.



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

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





[DBAL-793] [GH-516] The primary key columns don't have to be in the same order as the table columns Created: 17/Jan/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

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

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


 Description   

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

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

Message:

This happens when the columns are created in a different order then in the PK. This doesn't happen with Doctrine, as the order is taken from the PK.



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-792] [GH-515] Fix sqlite autoincrement detection Created: 17/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

When there are 2 PK-columns the code would still mark the first column as autoincrement.



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

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





[DBAL-791] [GH-514] [DBAL-789] Fix default values for TEXT/BLOB column type on MySQL Created: 16/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

MySQL does not support default values for `TEXT` and `BLOB` type columns. This causes `CREATE TABLE` statements to fail if a default value is supplied for those column types:

```sql
Doctrine\DBAL\DBALException: An exception occurred while executing 'CREATE TABLE text_blob_default_value (def_text LONGTEXT DEFAULT 'def' NOT NULL, def_text_null LONGTEXT DEFAULT 'def', def_blob LONGBLOB DEFAULT 'def' NOT NULL, def_blob_null LONGBLOB DEFAULT 'def') DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':

SQLSTATE[42000]: Syntax error or access violation: 1101 BLOB/TEXT column 'def_text' can't have a default value
```

Additionally useless `ALTER TABLE` statements are created for those mappings with the schema tool because online and offline schema differ for those column types concerning default values:

```sql
ALTER TABLE creative CHANGE filename filename LONGTEXT DEFAULT '' NOT NULL;
```



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

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





[DBAL-789] Default value not allowed on blob/text Created: 16/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

Type: Bug Priority: Major
Reporter: Klaus Jørgensen Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

LAMP



 Description   

introduced between v2.4.1 and v2.4.2

Doctrine is trying to set a default value on a LONGTEXT, it is not allowed in MySQL and ignored - resulting in an invalid schema and migration generating the same migration over and over again.

mysql> ALTER TABLE creative CHANGE filename filename LONGTEXT DEFAULT '' NOT NULL;
Query OK, 0 rows affected, 1 warning (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 1

mysql> show warnings;
-------------------------------------------------------------------

Level Code Message

-------------------------------------------------------------------

Warning 1101 BLOB/TEXT column 'filename' can't have a default value

-------------------------------------------------------------------
1 row in set (0.00 sec)



 Comments   
Comment by Steve Müller [ 16/Jan/14 ]

Thank you for reporting this issue. Patch supplied in PR: https://github.com/doctrine/dbal/pull/514

Comment by Doctrine Bot [ 08/Feb/14 ]

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





[DBAL-787] [GH-512] Fix modifying limit/offset for statements with subqueries on SQL Server Created: 14/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

Message:

`SELECT` statements that contains subqueries in the `SELECT` clause do not get properly rewritten with a limit and/or offset applied to it resulting in wrong SQL.

*Example*
```sql
SELECT foo.id, (SELECT COUNT FROM bar) AS bar_count FROM foo
```

*Expected with a limit of 10*
```sql
SELECT * FROM (SELECT foo.id, (SELECT COUNT FROM bar) AS bar_count, ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS doctrine_rownum FROM foo) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10
```

*Actual with a limit of 10*
```sql
SELECT * FROM (SELECT foo.id, (SELECT COUNT, ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS doctrine_rownum FROM bar) AS bar_count FROM foo) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10
```

The `ROW_NUMBER() OVER` clause is misplaced into the subselect instead of into the main `FROM` clause.
What this PR does is recursively matching any (nested) parentheses inside the main `SELECT` clause to be able to identify the main `FROM` clause to add the `ROW_NUMBER() OVER` clause to.
This of course is far from perfect for matching all kinds of possible `SELECT` statement syntaxes but it fixes this particular issue, which is pretty common IMO.



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

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





[DBAL-784] [GH-509] Fix table lock hints on SQL Anywhere Created: 13/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

`SQLAnywherePlatform::appendLockHint()` should not throw an exception if an unknown lock mode is given but rather return the unmodified `FROM` clause instead. This is especially required for ORM to work as it passes `null` by default which currently causes SQL Anywhere platform to throw an exception.



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

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





[DBAL-782] [GH-507] Fix unique indexes in CREATE TABLE statements on SQL Anywhere Created: 13/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

SQL Anywhere seems to distinguish between unique indexes and unique constraints. Unique constraints do not allow `NULL` values while unique indexes do.

A UNIQUE constraint is not the same as a unique index. Columns of a unique index are allowed to be NULL, while columns in a UNIQUE constraint are not. Also, a foreign key can reference either a primary key or a UNIQUE constraint, but cannot reference a unique index since a unique index can include multiple instances of NULL.

The current implementation create unique constraints instead of unique indexes during `CREATE TABLE` statements which causes ORM to fail as all nullable columns in a unique constraint silently get converted to `NOT NULL`.
This PR replace unique constraints by unique indexes in `CREATE TABLE`.



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

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





[DBAL-786] [GH-511] Create the online table before listing it. Created: 14/Jan/14  Updated: 15/Jan/14  Resolved: 15/Jan/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

```phpunit --filter testDiffListTableColumns``` fails because the test is currently relying on another test to have created the list_table_columns table.

It also fails in our driver, which is now packaged separately and so runs a slightly different test order.

I assume that was not the intention when the test was created. So, this branch adds the CREATE TABLE.



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

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

Comment by Marco Pivetta [ 15/Jan/14 ]

Merged: https://github.com/doctrine/dbal/commit/0a7df7c58aeab4d1cef55a78e5ca50299a12a62b





[DBAL-785] [GH-510] Exclude HHVM + PostgreSQL build matrix on Travis for now Created: 14/Jan/14  Updated: 14/Jan/14  Resolved: 14/Jan/14

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

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


 Description   

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

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

Message:

PR #498 introduced an extended build matrix for different PostgreSQL versions on Travis which should be excluded for HHVM as it does not currently support PostgreSQL.



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

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





[DBAL-779] [GH-505] Add SMALLSERIAL type support on PostgreSQL 9.2 platform Created: 10/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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: 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/505

Message:

Since PostgreSQL 9.2 there also is autoincrement support for `SMALLINT` type columns. The type to use is called `SMALLSERIAL`. This PR adds support for smallint autoincrement columns on `PostgreSQL92Platform`.
Please not that no further type mapping is necessarry, as `SMALLSERIAL` columns internally map to smallint in PostgreSQL which is already covered by `PostgreSQLPlatform`.



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

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





[DBAL-780] [GH-506] [DBAL-752] Fix integer type declaration SQL on SQLite Created: 10/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

This PR is complementary to https://github.com/doctrine/dbal/commit/6bd046d3bb1212bfd2808368a7143c9d95e3c157 and fixes also the type declaration SQL for integers on SQLite.



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

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





[DBAL-771] [GH-499] [DBAL-509] Quote identifiers in connection if necessary Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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: Invalid 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/499

Message:

Quotes identifiers in `Doctrine\DBAL\Connection` if necessary.



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

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





[DBAL-770] [GH-498] Add travis build matrix for all built-in PostgreSQL versions Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/14

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

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


 Description   

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

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

Message:

[Travis now ships with PostgreSQL version 9.1, 9.2 and 9.3 built-in](http://about.travis-ci.org/blog/2013-11-29-postgresql-92-93-now-available/). We should extend our build matrix to test on all versions.



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

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





[DBAL-769] [GH-497] Add dependency badge to the README Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/14

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

Type: Documentation 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 reiz:

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

Message:

I added version 2.4 to the README and added dependency badges. dev-master, 2.4 and 2.3 are up-to-date. Version 2.2 is outdated.



 Comments   
Comment by Robert Reiz [ 08/Jan/14 ]

Just updated the pull request on GitHub and details of this ticket.

Comment by Doctrine Bot [ 08/Jan/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/63ea7df5a5cec43f22b5cd4db9a347328f9d0c3b





[DBAL-775] [GH-501] Exclude HHVM + PostgreSQL and HHVM + Mysqli from travis build matrix Created: 08/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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: 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/501

Message:

HHVM currently does not support `pdo_pgsql` and `mysqli` drivers and therefore it is useless to test those combinations in the Travis build matrix.



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

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





[DBAL-776] [GH-502] [DBAL-764] Document types / column usage properly Created: 09/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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: 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/502

Message:

This PR massively improves the documentation of available DBAL types and also adds adds the documentation for the `Doctrine\DBAL\Schema\Column` class, its proper usage, capabilities and limitations concerning vendor support and portability.



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

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





[DBAL-767] [GH-495] Fix DataAccess test on HHVM Created: 05/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/14

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

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


 Description   

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

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

Message:

HHVM expects constructor arguments to be `null` in `PDOStatement::setFetchMode()` when using `\PDO::FETCH_CLASS` with custom class that does not have a constructor.

```php
PDOException: SQLSTATE[HY000]: General error: user-supplied class does not have a constructor, use NULL for the ctor_params parameter, or simply omit it
```



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

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





[DBAL-765] [GH-494] Refactor, consolidate and extend driver exception conversion Created: 05/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

This PR aims to have are more solid, abstracted and flexible driver exception conversion API as introduced in PR #364.
It removes the `DBALExcpetion::ERROR_*` constants in favour of returning the appropriate DBAL driver exception directly in the driver. Those constants are of no meaning anymore, as these exceptions get converted into dedicated exception instances anyways. This also allows custom driver implementations to handle their driver exception conversion manually and introducing custom driver exception classes. Moreover it saves one additional conversion step in `DBALException`.
A new `DriverException` interface has been introduced for driver exception to return the error code, SQLSTATE and message. This is an approach to have a uniform driver API just like `Driver`, `Connection` and `Statement`. This also offers some other opportunities.
Complementary the `AbstractDriverException` and `PDOException` classes have been introduced to provide the basic implementation and behaviour for driver exceptions.
`PDOConnection` and `PDOStatement` now wrap all method calls into try catch blocks, catch `\PDOException` and wrap it into DBAL's `PDOException` to provide DBAL's `DriverException` interface.
The API of the `ExceptionConverterDriver` has been changed to take the DBAL generated exception message and a `DriverException` instance to evaluate the driver specific error code and SQLSTATE in order to return the appropriate standardized DBAL driver exception instance.
The following DBAL driver exception class changes have been made:

  • Introduce a base `DriverExcpetion` class for all DBAL driver exceptions.
  • Introduce a `ConnectionException` class for all errors related to connection attempts (an abstraction just like the vendors do)
  • Introduce a `ServerException` class for all error related to operations made on the server (after the connection has succeeded, an abstraction just like the vendors do)
  • Introduce a `DatabaseObjectNotFoundException` class as a base class for referenced database objects like schemas, table, constraints, indexes etc. that do not exists in the database (useful also for SQL Server which cannot distinguish between unknown tables, sequences, indexes etc.).
  • Introduce a `DatabaseObjectExistsException` class as a base class for referenced database objects like schemas, table, constraints, indexes etc. that do already exists in the database (useful also for SQL Server which cannot distinguish between already existing tables, sequences, indexes etc.).
  • Introduce a `ConstraintViolationException` class as a base class for all constraint violations like foreign key constraints, unique constraints, not null constraints, check constraints etc. (useful also if you only want to determine whether a data intergrity problem was found)
  • Remove `AccessDeniedException` in favour of `ConnectionException`. The term "access denied" should be reserved for insufficient privileges on a database operation IMO. This exception until now also refered to network errors, unknown hosts etc. errors during a connection attempt. So IMO the term is misleading and should be changed to a more general connection error exception.
  • Rename `NotNullableException` to `NotNullConstraintViolationException` as it is a constraint in general and should also be named as such.
  • Renamed `DuplicateKeyException` to `UniqueConstraintViolationException` as it is a constraint and should also be named as such.
  • Removed `FailedToOpenException` and mapped it to `ConnectionException` as it is a SQLite specific exception and should be treated in a more general/abstracted sense.
  • Map `ReadOnlyException` to `ServerException` as it can only occurr if the connection has been established already. It was a connection error before.

There are a lot of changes that have been made but I think they are reasonable and important to have a better abstracted exception API. Also I would like to introduce a `Configuration` option for custom driver exception conversion which is only possible with this approach.

I hope you will like it, otherwise blame me to death!



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

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





[DBAL-762] [GH-491] Fix SQL Server drivers functional test suite and drivers Created: 04/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/14

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

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


 Description   

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

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

Message:

This should finally fix the functional test suites for SQL Server's `sqlsrv` and `pdo_sqlsrv` drivers. It introduces the following changes:

Please also note that the functional test suite will still fail if the underlying SQL Server database does not support SQL Azure as there currently is no reasonable way to distinguish those tests from SQL Server. Otherwise the tests now all pass!



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

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





[DBAL-759] [GH-489] Fix driver error while introspecting sequences in SQL Server 2012 Created: 02/Jan/14  Updated: 03/Jan/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
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/489

Message:

It seems the SQL Server drivers don't like SQL Server's special `sql_variant` data type when retrieving data from such columns. Therefore introspecting Sequences in SQL Server 2012 generates the following error:

```php
Fatal error: Unexpected SQL type encountered in calc_string_size. in C:\cygwin\home\Administrator\dev\dbal\lib\Doctrine\DBAL\Driver\SQLSrv\SQLSrvStatement.php on line 226
```

A workaround this limitation is to cast the specific columns to `VARCHAR` in the query.



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

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





[DBAL-758] [GH-488] Fix integer type mapping in SQL Anywhere 16 Created: 02/Jan/14  Updated: 03/Jan/14  Resolved: 03/Jan/14

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

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


 Description   

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

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

Message:

SQL Anywhere 16 seems to have changed the return value of integer type columns from `int` to `integer` when introspecting table columns. This causes the functional test suite to fail.



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

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





[DBAL-768] [GH-496] Add missing type parameters to connection fetch methods Created: 05/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/14

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

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

Issue Links:
Duplicate
duplicates DBAL-325 [GH-186] Added third an optional argu... Resolved

 Description   

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

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

Message:

Some `fetch*()` methods are missing the `$type` parameter in `Doctrine\DBAL\Connection`. This is a replacement for PR #186.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/5b9e6a999727a46ba3b808dc0e1acce2e7713730





[DBAL-763] [GH-493] Unit Test for getTableWhereClause method Created: 04/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/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: Incomplete Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-733 [GH-466] Error on PostgreSQL 9.3 REVE... Resolved

 Description   

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

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

Message:

Unit Test for the commit #492 [Fix statement for getTableWhereClause method](
https://github.com/doctrine/dbal/pull/492)



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

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

Comment by Doctrine Bot [ 05/Jan/14 ]

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

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

The unit test contained errors and was incomplete. It could not be done this way.





[DBAL-755] [GH-486] Add mysqli data seek support Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

http://php.net/manual/en/mysqli-result.data-seek.php
Usefull to reset results cursor after fetch one result



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

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





[DBAL-754] [GH-485] 2.4 Add mysqli data seek support Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

http://php.net/manual/en/mysqli-result.data-seek.php
Usefull to reset results cursor after fetch one result



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

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





[DBAL-752] Fix handling of unsigned integers on Sqlite Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Comments   
Comment by Benjamin Eberlei [ 31/Dec/13 ]

See https://github.com/doctrine/dbal/commit/6bd046d3bb1212bfd2808368a7143c9d95e3c157





[DBAL-751] [GH-484] Implement ExceptionConverterDriver in Oracle drivers Created: 30/Dec/13  Updated: 31/Dec/13  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: 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/484

Message:

Complementary to PR https://github.com/doctrine/dbal/pull/364.



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

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





[DBAL-750] [GH-483] Fix parsing SQL Server bracket delimiters in SQL statements Created: 30/Dec/13  Updated: 31/Dec/13  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: 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/483

Message:

Currently `SQLParserUtils` does not take SQL Server's bracket identifier delimiters into account when parsing parameter placeholders. Colons and question marks should not be considered as parameter placeholder in explicitly quoted identifiers (as is the case already for single quoted, double quoted and backtick quoted identifiers).

*Example*
```sql
SELECT [column?], [ns::column], [column], foo, ? FROM bar
```
The `SQLParserUtil` should detect exactly one placeholder here.



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

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





[DBAL-749] [GH-482] Fix some assertion and CS in schema manager functional tests Created: 30/Dec/13  Updated: 31/Dec/13  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: 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/482

Message:

See discussion in PR https://github.com/doctrine/dbal/pull/481



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

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





[DBAL-748] [GH-481] Fix Oracle test suite Created: 29/Dec/13  Updated: 30/Dec/13  Resolved: 30/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 deeky666:

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

Message:

Final fixes for the Oracle test suite to run again without errors:

```bash
deeky@98N-MUELLER-STEVE:~/dev/doctrine/dbal$ phpunit -c oci8.phpunit.xml
PHPUnit 3.7.27 by Sebastian Bergmann.

Configuration read from /home/deeky/dev/doctrine/dbal/oci8.phpunit.xml

..........................................................SSS 61 / 1578 ( 3%)
S.............................S.SS...SSSSSSSSSSSSSS.S.SSSSS.. 122 / 1578 ( 7%)
..SSS.....................SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 183 / 1578 ( 11%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS..........S.......S 244 / 1578 ( 15%)
......SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 305 / 1578 ( 19%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 366 / 1578 ( 23%)
S..SSS..SS.S.........................S....................... 427 / 1578 ( 27%)
............................................................. 488 / 1578 ( 30%)
............................................................. 549 / 1578 ( 34%)
............................................................. 610 / 1578 ( 38%)
...........................................................S. 671 / 1578 ( 42%)
............................................................. 732 / 1578 ( 46%)
.....................................S......S................ 793 / 1578 ( 50%)
............................................................. 854 / 1578 ( 54%)
......................S.....S................................ 915 / 1578 ( 57%)
............................................................. 976 / 1578 ( 61%)
............................................................. 1037 / 1578 ( 65%)
............................................................. 1098 / 1578 ( 69%)
.......................................................SSS... 1159 / 1578 ( 73%)
............................................................. 1220 / 1578 ( 77%)
............................................................. 1281 / 1578 ( 81%)
............................................................. 1342 / 1578 ( 85%)
................S............................................ 1403 / 1578 ( 88%)
............................................................. 1464 / 1578 ( 92%)
.....S..SSS.................................................. 1525 / 1578 ( 96%)
.....................................................

Time: 2.19 minutes, Memory: 50.25Mb

OK, but incomplete or skipped tests!
Tests: 1578, Assertions: 2852, Skipped: 246.
```

*Changes*

  • Skip tests for unsupported rollback of DDL statements during transactions

And finally... HALLELUJAH! :+1:

  • Fix default NULL value (again) containing trailing whitespace when retrieved from database
  • Fix drop and create database test by utilizing temporary connection in favour of real connection which has sufficient privileges and changing database name to match Oracle 12c requirements


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

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





[DBAL-757] Add automatic platform version detection Created: 02/Jan/14  Updated: 16/Feb/14  Resolved: 16/Feb/14

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

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


 Description   

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

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

Message:

As more and more vendor version specific platforms evolve, it is time to make an approach of autodetecting and using the correct platform on connection. This is done by introducing two new interfaces `Doctrine\DBAL\VersionAwarePlatformDriver` and `Doctrine\DBAL\Driver\ServerInfoAwareConnection` which are implemented by Doctrine's driver and driver connection classes. They are introduced to keep BC for custom driver / driver connection classes.
`VersionAwarePlatformDriver::createDatabasePlatformForVersion($version)` is responsible for evaluating a given vendor specific version number and instantiating the correct platform for it. The current implementations normalize the given version string and use `version_compare()` for evaluation.
`ServerInfoAwareConnection::getServerVersion()` is responsible for returning the normalized version string of the database server currently connected to. `ServerInfoAwareConnection::requiresQueryForServerVersion()` defines whether receiving that information requires an additional database query or not which is important for `Doctrine\DBAL\Connection` as described in the following.
`Doctrine\DBAL\Connection` now takes an additional (optional) connection parameter `serverVersion` which the user can pass to skip platform autodetection and define the desired platform version straight away. This is also required for drivers that cannot return the database server version without an additional query (performance reasons). Platform version detection is now done in the following order of precedence:

1. Evaluate `platform` connection parameter and return an instance of that class if given.
2. Evaluate if the underlying driver is capable of creating platform instances by version. If not, return the default platform instance that would be returned by the current implementation.
3. Evaluate if `serverVersion` connection parameter is given and return the appropriate platform instance for that version.
4. Evaluate if the underlying driver connection can return the server version and can return it without the need of an additional query -> return the appropriate platform instance for that version.
5. Otherwise return the default platform instance that would be returned by the current implementation.

As a positive side effect while implementing the new interfaces, the driver classes were refactored by extracting abstract base driver classes for each vendor. This removes a lot of duplicated code in the driver classes that are related to the same database vendor. Please also note, that `DrizzlePDOMySql` now directly inherits from `Doctrine\DBAL\Driver\PDOMySql\Driver` to come around additional code duplication.

The only BC break introduced by this PR should be the visibility change of `Doctrine\DBAL\Connection::$_platform` from protected to private (as wished by @beberlei).
The only drawback of this implementation is that `Doctrine\DBAL\Connection::getDatabasePlatform()` now needs to do the real connect (if uninitialized) under some circumstances when it needs to autodetect the server version from the driver connection. Therefore I had to change the initialization of temporary connections in the functional test suite a little bit, so that calling `Doctrine\DBAL\Connection::getDatabasePlatform()` does not raise an error if the supplied temporary database does not exist. I think this is acceptable as it is not necessary to connect to a specific database anyways when only needing to drop and create the real test database.

As soon as the doctrine team agrees on this approach, I will add some more test and documentation for this. Until then this is a WIP PR.



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

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





[DBAL-756] Allow platforms to return the vendor instead of version specific names as well Created: 01/Jan/14  Updated: 01/Jan/14  Resolved: 01/Jan/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

New method `getVendor` required.






[DBAL-747] [GH-480] [DBAL-558] Fix parsing parameters in quoted text with backslash Created: 29/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

Message:

Parsing SQL statements that contain single backslashes in quoted text breaks retrieving unquoted statement fragments.

*Example*
```sql
SELECT * FROM foo WHERE bar = 'Doctrine\DBAL\SQLParserUtils'
```



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

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





[DBAL-745] [GH-478] Add missing driver exception subclasses Created: 29/Dec/13  Updated: 30/Dec/13  Resolved: 30/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 deeky666:

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

Message:

Complementary to https://github.com/doctrine/dbal/pull/458/files



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

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





[DBAL-743] [GH-476] Fix foreign key propagation on non-supporting MySQL table engines Created: 28/Dec/13  Updated: 11/Jan/14  Resolved: 29/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

Issue Links:
Reference
is referenced by DBAL-795 Error: "database schema is not in syn... Resolved

 Description   

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

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

Message:

`CREATE TABLE` and `ALTER TABLE` statements on MySQL should not propagate foreign key constraint creation/alteration on non-supporting table engines. This is a fix for a migrations issue discussed in https://github.com/doctrine/migrations/issues/43.






[DBAL-738] [GH-471] [DBAL-685] Add servicename connection parameter to Oracle drivers Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 deeky666:

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

Message:

Currently Doctrine's Oracle drivers do not distinguish between `SID` / `SERVICE_NAME` and `DBNAME` connection parameters which do not necessarily have to be the same in every database environment setup. The `SID` is the unique name of the database instance to connect to and can be superseded by a more general `SERVICE_NAME` which can be configured to contain multiple database instances in a HA environment on server side. For each individual database environment setup to work we need to be able to specify different values for `SID` / `SERVICE_NAME` and `DBNAME`.
This PR adds an additonal `servicename` connection parameter which is used instead of `dbname` for the `SID` / `SERVICE_NAME` connection parameters *IF* given. I also updated the docs to cover this and another parameter `service` which was introduced in DBAL-141(http://www.doctrine-project.org/jira/browse/DBAL-141) but never got documented.






[DBAL-740] [GH-473] [DBAL-234] Add support for renaming indexes Created: 28/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 deeky666:

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

Message:

Currently renamed only indexes are scheduled for removal and recreation in the comparator. However recreating an index when only the name has changed is very inefficient on large tables as it internally requires a table recreation on most of the platforms. Many vendors offer a more efficient syntax for renaming indexes which saves the table recreation. This PR introduces this behaviour on capable platforms. Platforms that do not support this kind of syntax still use the current behaviour of dropping and recreating an index.
This PR also introduces the `Table::renameIndex()` method and the `MySQL57Platform` platform which adds [support for explicitly renaming indexes](http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html).



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/6d0e8e2a8598f121cdb136507022915247fc98b8





[DBAL-737] [GH-470] Connection: Replaced ! is_int with is_string Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 mishak87:

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

Message:

Intended side effect is not to call extractTypeValues when $types array is empty which it is by default.

It should be clear from commit.

`! is_int(key([])` => `true`
`is_string(key[])` => `false`



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

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





[DBAL-739] [GH-472] Fix index flags Created: 28/Dec/13  Updated: 28/Dec/13  Resolved: 28/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: Steve Müller
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/472

Message:

`Index` does not consistently use the defined property `$_flags` throughout the flag methods. Therefore `Index::getFlags()` does not return the defined flags.



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

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

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

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





[DBAL-734] [GH-467] [DBAL-472] Fix altering column from notnull to null in Oracle Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 deeky666:

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

Message:

Oracle requires an explicit `NULL` clause when altering a column from `NOT NULL` to `NULL`. Otherwise the existing notnull constraint remains unchanged.
This PR changes Oracles column declaration SQL snippet to always specify `NULL` and `NOT NULL` in `CREATE TABLE` and `ALTER TABLE` statements. This is a perfectly valid syntax and also functional tested.



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

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





[DBAL-733] [GH-466] Error on PostgreSQL 9.3 REVERSE ENGINEERING tables Created: 27/Dec/13  Updated: 05/Jan/14  Resolved: 05/Jan/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: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-763 [GH-493] Unit Test for getTableWhereC... Resolved

 Description   

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

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

Message:

"Table xxxxx_xxxxx has no primary key. Doctrine does not support reverse engineering from tables that don't have a primary key."

This table was on PUBLIC schema and with a PK composed by 3 fields.



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

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

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

The provided fix is invalid and caught by PR:
https://github.com/doctrine/dbal/pull/492

Comment by Doctrine Bot [ 05/Jan/14 ]

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





[DBAL-735] [GH-468] Fix dropping table without autoincrement trigger in Oracle Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 deeky666:

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

Message:

Autoincrement primary key columns are implemented as a triggers that emulate autoincrementation in Oracle. Dropping tables with Oracle's schema manager first drops those triggers before actually dropping the table. However when there is no such trigger (either if the primary key was not defined as autoincrement column or the trigger could not be found on database side) dropping the table via schema manager fails silently and the table still exists. Dropping those triggers should not cause the schema manager to skip executing the `DROP TABLE` statement. Therefore this PR wraps dropping the trigger into a `tryMethod()` so that it can fail and still call the actual `dropTable` operation.
This also fixes a lot of failing functional tests in Oracle's test suite where tables without autoincrement primary keys column are created and dropped.



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

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





[DBAL-728] [GH-462] Fix full qualified table name schema introspection Created: 23/Dec/13  Updated: 29/Dec/13  Resolved: 29/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

Issue Links:
Duplicate
duplicates DBAL-701 [GH-442] Fixed renaming of MSSQL columns Resolved

 Description   

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

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

Message:

Currently SQL Server and SQL Anywhere don't respect full qualified table names when using `getList*()` methods on the platforms. This PR fixes this and adds a general functional test for vendors supporting schemas.
This is a replacement for PR #442.



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

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





[DBAL-736] [GH-469] [DBAL-553] Add support for native JSON type on capable platforms Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/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: 1
Labels: None


 Description   

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

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

Message:

PostgreSQL introduced a native JSON type in version 9.2. This PR adds support for native JSON type declarations on capable platforms (currently only PostgreSQL). The implementation is adopted form the native GUID type support.



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

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





[DBAL-729] [GH-463] Fix table alteration on Drizzle Created: 23/Dec/13  Updated: 29/Dec/13  Resolved: 29/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 deeky666:

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

Message:

PR #452 silently introduced a bug in `DrizzlePlatform::getAlterTableSQL()` which gets fixed by this PR.



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

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





[DBAL-721] [GH-457] Fix composite primary key introspection on Sqlite Created: 22/Dec/13  Updated: 22/Dec/13  Resolved: 22/Dec/13

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

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


 Description   

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

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

Message:

Running the Sqlite testsuite I get the following error:

```bash
There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\Schema\SqliteSchemaManagerTest::testListTableIndexes
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (
0 => 'id'

  • 1 => 'other_id'
    )

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

This is due to the schema manager not correctly building composite primary keys on Sqlite. I don't know why this does not fail on Travis but accoding to the [official documentation](http://www.sqlite.org/pragma.html#pragma_table_info) this approach is the correct implementation.
I did not add a dedicated test for this as there obviously already is one that covers this.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/0724b0257f38bfad34485e11261fad3050287366





[DBAL-725] [GH-460] [DBAL-593] Add more documentation about vendors and platforms Created: 22/Dec/13  Updated: 22/Dec/13  Resolved: 22/Dec/13

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

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


 Description   

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

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

Message:

This PR lists all supported RDBMS vendors in the introduction to have an overview of those in the first place. Also some more words about the purpose and usage of different platform classes has been added.



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

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





[DBAL-724] [GH-459] [DBAL-544] Fix reference to legacy Query::HYDRATE_* constants in ResultStatement documentation Created: 22/Dec/13  Updated: 22/Dec/13  Resolved: 22/Dec/13

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

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


 Description   

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

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

Message:

The documentation of the `ResultStatement` interface refers to `Query::HYDRATE_*` constants to use as fetch style. This is wrong. I guess this is a legacy problem from Doctrine 1.



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

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





[DBAL-727] [GH-461] [DBAL-726] Fix portability statement parameter binding delegation Created: 23/Dec/13  Updated: 23/Dec/13  Resolved: 23/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