[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-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 17/Apr/14  Resolved: 21/May/13

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

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-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-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 Open

 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-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-783] [GH-508] [DDC-2310] Fix evaluation of NOLOCK table hint on SQL Server Created: 13/Jan/14  Updated: 31/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

Issue Links:
Reference
relates to DDC-2310 Recent changes to DBAL SQL Server pla... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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





[DBAL-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 Assignee: Guilherme Blanco
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/461

Message:

Portability `Statement::bindParam($column, &$variable, $type = null, $length = null)` does not delegate the `$length` parameter to the underlying statement.



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

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

Comment by Marco Pivetta [ 23/Dec/13 ]

Merged: https://github.com/doctrine/dbal/commit/2196da9cd9fc72e343560fce818affbcfbdf93d0





[DBAL-723] [GH-458] [DBAL-722] Introduce subclasses for runtime relevant exceptions 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 beberlei:

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

Message:



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

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

Comment by Benjamin Eberlei [ 22/Dec/13 ]

Completes DBAL-407





[DBAL-726] Portability bindParam ignores length parameter Created: 23/Dec/13  Updated: 23/Dec/13  Resolved: 23/Dec/13

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

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


 Description   

Method bindParam in Doctrine\DBAL\Portability\Statement ignores parameter $length



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

PR: https://github.com/doctrine/dbal/pull/461

Comment by Doctrine Bot [ 23/Dec/13 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/2196da9cd9fc72e343560fce818affbcfbdf93d0





[DBAL-722] Introduce subclasses for runtime relevant exceptions 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: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


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

Implemented in DBAL-723, completes DBAL-407





[DBAL-719] [GH-455] [Mysqli] MYSQLI_SERVER_PUBLIC_KEY only exist for php5.5.0 or creater wit... 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 kimhemsoe:

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

Message:

...h mysqlnd.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/37e7727c44f977b172d63a75b3f10b8bea3e3fcf





[DBAL-716] [GH-453] [DBAL-555] Fix using Identifier assets and quoting Created: 20/Dec/13  Updated: 21/Dec/13  Resolved: 21/Dec/13

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

Type: Bug Priority: Major
Reporter: 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 beberlei:

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

Message:

This is an alternative to GH-367



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

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

Comment by Doctrine Bot [ 21/Dec/13 ]

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





[DBAL-718] [GH-454] Add documentation for query builder insert operation 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/454

Message:

Documentation for PR #420.



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

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





[DBAL-717] Cannot reconnect to slave in some cases of keepSlave Created: 21/Dec/13  Updated: 03/Jan/14  Resolved: 21/Dec/13

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

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

Issue Links:
Duplicate
is duplicated by DBAL-527 [GH-323] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-531 [GH-325] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-519 MasterSlave connection does not keep ... Resolved

 Description   

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



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

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





[DBAL-714] [GH-452] Introduce BinaryType Created: 20/Dec/13  Updated: 03/Jan/14  Resolved: 22/Dec/13

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

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

Issue Links:
Reference
is referenced by DBAL-122 Impossible to save data to image/bina... Resolved

 Description   

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

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

Message:

This PR introduces a `BinaryType` as an equivalent to `StringType` for binary strings of varying and fixed length as an alternative to `BlobType` for smaller data requirements. Most of the vendors have native support for `BINARY` and `VARBINARY` types which get mapped to this type. Currently `Sqlite` and `PostgreSQL` don't support them and mapping falls back to their native `BLOB` types when `BinaryType` is used in the application.
Please not that the added methods `AbstractPlatform::getBinaryMaxLength()` and `AbstractPlatform::getBinaryDefaultLength()` are not used consistently throughout the platforms. I decided to adopt each platform's behaviour concerning default and max lengths evaluation if favour of implementing it the "correct" way. The reason for this is that those values are not properly defined and used throughout the platform and I guess changing this behaviour would be a BC break.
An example to illustrate what I mean:
Most of the vendors use a default length for `VARCHAR` / `CHAR` / `VARBINARY` / `BINARY` of `1` when you don't provide a length specifier in the declaration. However most of the platforms use a default of `255` and there are even many places where this value is hardcoded. At least this is my understanding of the default value.



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

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





[DBAL-713] MSSQL: Wrong Placement of "ROW_NUMBER() OVER" when using Subqueries in SELECT part Created: 19/Dec/13  Updated: 18/Feb/14  Resolved: 15/Feb/14

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

Type: Bug Priority: Major
Reporter: M.K. Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: sqlserver
Environment:

PHP 5.4.4 (with pdo_sqlsrv extension)
Windows 7



 Description   

I'm trying to create a DQL query like that:

SELECT Task.id AS id, Task.date AS date, (
	SELECT COUNT(p.posNr)
	FROM Project\Entity\Position p
	WHERE Task.id=p.ref
) AS poscount
FROM Project\Entity\Task Task
WHERE Task.id <> 0 AND Task.status < 3
ORDER BY Task.date DESC

This works flawlessly on MSSQL until i try to apply a LIMIT/OFFSET by using setFirstResult() and setMaxResults().
Applying a Limit results in an invoke of "doModifyLimitQuery()" in "Doctrine\DBAL\Platforms\SQLServerPlatform".

The function implementation clearly states what's wrong:

//Replace only first occurrence of FROM with $over to prevent changing FROM also in subqueries.
$over  = 'ORDER BY ' . implode(', ', $overColumns);
$query = preg_replace('/\sFROM\s/i', ", ROW_NUMBER() OVER ($over) AS doctrine_rownum FROM ", $query, 1);

This breaks support with subqueries in SELECT statements.



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

Yeah this seems to be indeed wrong. This method is going one step forward and one step back with each adjustment I don't feel comfortable trying to fix that one as it is really sensitive. But you are welcome to provide a patch for this on github (or someone else).

Comment by Tom Drissen [ 14/Jan/14 ]

I ran into this bug today, which is really annoying. Is there any change this will be fixed shortly?
How about checking parenthesises to determine the 'base' FROM/table?

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

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

Comment by Doctrine Bot [ 08/Feb/14 ]

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

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

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

Comment by M.K. [ 18/Feb/14 ]

Important Notice:

The usage of preg_replace() in this bugfix can cause Apache to abort the PHP execution because of a stack overflow.
Apache's default value for "ThreadStackSize" on Windows is 1MB. This is not sufficient if you use preg_replace() on long queries.
I had to increase the size to 8MB.
This should be mentioned somewhere.

Comment by Marco Pivetta [ 18/Feb/14 ]

M.K. how long is the query with which you are experiencing this? I'd say it's more a PHP bug than problem of the DBAL

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

That might be an issue of using recursion in the regular expression maybe. I'm not sure if that is known limitation of PHP. But it seems weird to me you have to adjust apache config instead of PHP for this.

Comment by M.K. [ 18/Feb/14 ]

My Query is 1275 characters long.

It's not a bug at all, just a misconfiguration in Apache. But it's really hard to debug this problem, because Apache just kills PHP and doesn't say a word about it. So it would be kind to document this somewhere, so that new Doctrine Users can configure their Apache correctly.





[DBAL-707] [GH-447] Fix IBM DB2 implementation / ibm_db2 driver Created: 17/Dec/13  Updated: 20/Dec/13  Resolved: 20/Dec/13

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

Type: 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/447

Message:

This PR is a first approach towards officially supporting IBM DB2 platform in DBAL. The current implementation of the platform and schema manager are very outdated, buggy and incomplete. There is no platform test case yet and running the general DBAL test suite shows a lot of errors.
The focus of this PR is to bring back the DB2 platform and schema manager into sync mit the abstract classes so that at least the test suite runs. Furthermore this PR adds a platform test case. Along with achieving this, a lot of bugs needed to be fixed. The following changes have been made:

  • Add support for `\PDO::FETCH_CLASS` and `\PDO::FETCH_OBJ` fetch modes in `ibm_db2` driver
  • Optimize table indexes introspection (cleaner list SQL statement and codebase in schema manager)
  • Fix foreign key constraints introspection (also cleaned up codebase in schema manager)
  • Introduce BLOB type column support
  • Fix `TRUNCATE TABLE` statement generation
  • Fix SQL snippets for current date/time/timestamp constants
  • Add date arithmetic expressions
  • Fix bit operator expressions
  • Add support for portability connection
  • Fix default value declarations
  • Fix renaming columns
  • Fix renaming tables
  • Fix autoincrement column introspection
  • Fix required table reorganization after table alteration
  • Fix `DROP DATABASE` statement generation
  • Remove unnecessary method overrides in the platform
  • Add platform test case

The complete test suite now runs fine on `ibm_db2` driver except for `TypeConversionTest::testIdempotentDataConversion`:

```bash
There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\TypeConversionTest::testIdempotentDataConversion with data set #13 ('decimal', 1.55, 'string')
Conversion between values should produce the same out as in value, but doesnt!
Failed asserting that '1,55' matches expected 1.55.

/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/TypeConversionTest.php:94
```

I have tried to find a solution for this issue but apparently this is a driver issue as the decimal separator seems to depend on the system's locale settings. Unfortunately there is no driver option where we could set the desired decimal separator. For now it seems we have to live with it and I guess it works on english locale systems.

The `pdo_ibm` driver reveals more problems as it is still buggy (for years now). The driver still [segfaults on decoding CLOB/BLOB resources](http://pecl.php.net/bugs/bug.php?id=17199). So every test that uses BLOBs in any way does not run. The second issue I encountered was a test where a table is referenced quoted in a `SELECT` statement:

```bash
There was 1 error:

1) Doctrine\Tests\DBAL\Functional\DataAccessTest::testPrepareWithQuoted
Doctrine\DBAL\DBALException: An exception occurred while executing 'SELECT test_int, test_string FROM "fetch_table" WHERE test_int = '1' AND test_string = 'foo'':

SQLSTATE[42S02]: Base table or view not found: -204 [IBM][CLI Driver][DB2/LINUXX8664] SQL0204N "DB2INST1.fetch_table" is an undefined name. SQLSTATE=42704
(SQLNumResultCols[-204] at /home/deeky/db2/PDO_IBM-1.3.3/ibm_driver.c:153)

/home/deeky/dev/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:110
/home/deeky/dev/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:50
/home/deeky/dev/doctrine/dbal/lib/Doctrine/DBAL/Statement.php:86
/home/deeky/dev/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:702
/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/DataAccessTest.php:154
```

This is weird and I couldn't find out why this does not work on `pdo_ibm` but works on `ibm_db2`.
Besides those issues `pdo_ibm` runs fine.

This PR does not make the IBM DB2 implementation perfect yet but it is a good start which is already usable. If we decide on officially supporting this vendor, I would do further work on this.



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

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





[DBAL-710] [GH-449] Document possible Sqlite datetime issues. Created: 17/Dec/13  Updated: 18/Dec/13  Resolved: 18/Dec/13

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

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

Message:

This may also be considered a bug instead.

```
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table tbl1(dt datetime);
sqlite> insert into tbl1 (dt) VALUES ('2013-05-20 00:56');
sqlite> insert into tbl1 (dt) VALUES ('foo');
sqlite> select * from tbl1;
2013-05-20 00:56
foo
sqlite> select datetime(dt) from tbl1;
2013-05-20 00:56:00

sqlite>
```

Discovered via https://github.com/owncloud/core/issues/6327
Refs https://github.com/owncloud/core/commit/f8088ecd29af75072f96a3841709faf72c6e8fa1



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

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





[DBAL-706] [GH-446] [DBAL-702] Add sslmode connection option to pdo_pgsql driver Created: 16/Dec/13  Updated: 18/Dec/13  Resolved: 18/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/446

Message:

Allows specifying whether or with what priority a secure SSL TCP/IP connection will be negotiated with the server in `pdo_pgsql` driver as requested in DBAL-702(http://www.doctrine-project.org/jira/browse/DBAL-702).
See: http://www.php.net/manual/en/ref.pdo-pgsql.connection.php#112685



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

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





[DBAL-709] [GH-448] [DBAL-577] Fix platform's IN expression Created: 17/Dec/13  Updated: 18/Dec/13  Resolved: 18/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: 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/448

Message:

`AbstractPlatform::getInExpression()` calls an undefined method `AbstractPlatform::getIdentifiers()`. This PR removes this call and also removes the raising of an exception in case of empty given values. The logic does not work when passing a string as `$values` parameter and furthermore other expression methods do not check the input parameters either. Besides that MySQL for example also accepts empty `IN()` expressions.



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

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

Comment by Benjamin Eberlei [ 18/Dec/13 ]

getInExpression() was removed, as never working and used.





[DBAL-708] Evaluate bigint, numeric Strings and PostgreSQL compatibility Created: 17/Dec/13  Updated: 01/Jan/14  Resolved: 01/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

See for details:

https://github.com/symfony/symfony/pull/9796
https://github.com/symfony/symfony/issues/7156



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

Issue is invalid





[DBAL-711] [GH-450] [DBAL-122] Fix BLOB type mapping in SQL Server platform Created: 18/Dec/13  Updated: 05/Jan/14  Resolved: 19/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-122 Impossible to save data to image/bina... Resolved

 Description   

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

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

Message:

This PR fixes mappings for database types `image` and `binary` in SQL Server which should be mapped to Doctrine's `BlobType`.
`image` is mapped to `VARBINARY(MAX)` in SQL Server internally. Mapping `binary` to `BlobType` is not 100% correct as it has a fixed length and is limited in its max size, but as long as we don't have a Doctrine type like `BinaryType`, this is definitly better than mapping it to `text` which is simply wrong.



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

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

Comment by Marco Pivetta [ 19/Dec/13 ]

Merged: https://github.com/doctrine/dbal/commit/c727c032a876e703ab964848ebf0a1eefed32a9a

Comment by Doctrine Bot [ 05/Jan/14 ]

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





[DBAL-712] [GH-451] Fix deprecated CLOB type declaration in SQL Server platform Created: 18/Dec/13  Updated: 20/Dec/13  Resolved: 20/Dec/13

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

Type: 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/451

Message:

According to the [SQL Server documentation](http://technet.microsoft.com/en-gb/library/ms187993.aspx) the `text` type declaration is deprecated and will be removed in the future. It is encouraged to use `varchar(max)` instead. This has been applied to `SQLServerPlatform::getClobTypeDeclarationSQL()` by this PR.
The `varchar(max)` declaration is BC for all SQL Server versions supported by Doctrine btw.



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

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





[DBAL-703] [GH-443] Added some documentation for the drizzle driver. Created: 12/Dec/13  Updated: 12/Dec/13  Resolved: 12/Dec/13

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: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 12/Dec/13 ]

Merged: https://github.com/doctrine/dbal/commit/8725da2950d9f9e87ea1a154888ee54a7c86a74b





[DBAL-702] Postgresql SSLconnection Created: 10/Dec/13  Updated: 18/Dec/13  Resolved: 18/Dec/13

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

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


 Description   

I cannot connect to my postgresql database using SSL. When I try, I get the following error:

SQLSTATE[08006] [7] FATAL: no pg_hba.conf entry for host "123.123.123.123", user "user", database "db", SSL off

I've tried to add to the options 'sslenabled' => true and 'ssl' => true, but it didn't work. What can I do, folks?



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

Unfortunately it is currently not possible to establish SSL enabled connections for pdo_pgsql as the DBAL driver only evaluates the parameters "host", "port" and "dbname". Any other connection parameter will be ignored by now.

Comment by Benjamin Eberlei [ 13/Dec/13 ]

We should add this functionality, see how it works here: http://www.php.net/manual/en/ref.pdo-pgsql.connection.php#112685

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

Okay I will add a driver option for this.





[DBAL-699] toSql() for Oracle table with auto increment column produces SQL errors Created: 05/Dec/13  Updated: 27/Dec/13  Resolved: 27/Dec/13

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

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

Oracle 10g



 Description   

I have a table with an ID column that is auto incremented, and I'm trying to use the Doctrine schema representation objects to generate the SQL.

But, the SQL that gets generated for Oracle results in errors when I try to run the SQL script.

The Oracle version we are using is "Oracle Database 10g Release 10.2.0.4.0 - 64bit Production." (on Windows)

I have this PHP code:

$schema = new Doctrine\DBAL\Schema\Schema();
$table = $schema->createTable('bvs_request');

$table->addColumn('brq_request_id', 'bigint', array('autoincrement' => true));
$table->addColumn('brq_policy_num', 'string', array('length' => 25));
$table->addColumn('brq_request_date', 'datetime', array('default' => 'CURRENT_TIMESTAMP'));
$table->setPrimaryKey(array('brq_request_id'));

$platform = new Doctrine\DBAL\Platforms\OraclePlatform();
$sql = $schema->toSql($platform);

... which generates this SQL:

CREATE TABLE bvs_request (brq_request_id NUMBER(20) NOT NULL, brq_policy_num VARCHAR2(25) NOT NULL, brq_request_date TIMESTAMP(0) DEFAULT CURRENT_TIMESTAMP NOT NULL, PRIMARY KEY(brq_request_id))
DECLARE
  constraints_Count NUMBER;
BEGIN
  SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'BVS_REQUEST' AND CONSTRAINT_TYPE = 'P';
  IF constraints_Count = 0 OR constraints_Count = '' THEN
    EXECUTE IMMEDIATE 'ALTER TABLE BVS_REQUEST ADD CONSTRAINT BVS_REQUEST_AI_PK PRIMARY KEY (BRQ_REQUEST_ID)';
  END IF;
END;
CREATE SEQUENCE BVS_REQUEST_BRQ_REQUEST_ID_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1
CREATE TRIGGER BVS_REQUEST_AI_PK
   BEFORE INSERT
   ON BVS_REQUEST
   FOR EACH ROW
DECLARE
   last_Sequence NUMBER;
   last_InsertID NUMBER;
BEGIN
   SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   IF (:NEW.BRQ_REQUEST_ID IS NULL OR :NEW.BRQ_REQUEST_ID = 0) THEN
      SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   ELSE
      SELECT NVL(Last_Number, 0) INTO last_Sequence
        FROM User_Sequences
       WHERE Sequence_Name = 'BVS_REQUEST_BRQ_REQUEST_ID_SEQ';
      SELECT :NEW.BRQ_REQUEST_ID INTO last_InsertID FROM DUAL;
      WHILE (last_InsertID > last_Sequence) LOOP
         SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO last_Sequence FROM DUAL;
      END LOOP;
   END IF;
END;

This is the result when trying to run the SQL in Oracle Developer:

Error starting at line 1 in command:
CREATE TABLE bvs_request (brq_request_id NUMBER(20) NOT NULL, brq_policy_num VARCHAR2(25) NOT NULL, brq_request_date TIMESTAMP(0) DEFAULT CURRENT_TIMESTAMP NOT NULL, PRIMARY KEY(brq_request_id))
DECLARE
  constraints_Count NUMBER
Error at Command Line:2 Column:1
Error report:
SQL Error: ORA-00922: missing or invalid option
00922. 00000 -  "missing or invalid option"
*Cause:    
*Action:

Error starting at line 4 in command:
BEGIN
  SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'BVS_REQUEST' AND CONSTRAINT_TYPE = 'P';
  IF constraints_Count = 0 OR constraints_Count = '' THEN
    EXECUTE IMMEDIATE 'ALTER TABLE BVS_REQUEST ADD CONSTRAINT BVS_REQUEST_AI_PK PRIMARY KEY (BRQ_REQUEST_ID)';
  END IF;
END;
CREATE SEQUENCE BVS_REQUEST_BRQ_REQUEST_ID_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1
CREATE TRIGGER BVS_REQUEST_AI_PK
   BEFORE INSERT
   ON BVS_REQUEST
   FOR EACH ROW
DECLARE
   last_Sequence NUMBER;
   last_InsertID NUMBER;
BEGIN
   SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   IF (:NEW.BRQ_REQUEST_ID IS NULL OR :NEW.BRQ_REQUEST_ID = 0) THEN
      SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   ELSE
      SELECT NVL(Last_Number, 0) INTO last_Sequence
        FROM User_Sequences
       WHERE Sequence_Name = 'BVS_REQUEST_BRQ_REQUEST_ID_SEQ';
      SELECT :NEW.BRQ_REQUEST_ID INTO last_InsertID FROM DUAL;
      WHILE (last_InsertID > last_Sequence) LOOP
         SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO last_Sequence FROM DUAL;
      END LOOP;
   END IF;
END;
Error report:
ORA-06550: line 7, column 1:
PLS-00103: Encountered the symbol "CREATE" 
06550. 00000 -  "line %s, column %s:\n%s"
*Cause:    Usually a PL/SQL compilation error.
*Action:
Error starting at line 4 in command:
BEGIN
  SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'BVS_REQUEST' AND CONSTRAINT_TYPE = 'P';
  IF constraints_Count = 0 OR constraints_Count = '' THEN
    EXECUTE IMMEDIATE 'ALTER TABLE BVS_REQUEST ADD CONSTRAINT BVS_REQUEST_AI_PK PRIMARY KEY (BRQ_REQUEST_ID)';
  END IF;
END;
CREATE SEQUENCE BVS_REQUEST_BRQ_REQUEST_ID_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1
CREATE TRIGGER BVS_REQUEST_AI_PK
   BEFORE INSERT
   ON BVS_REQUEST
   FOR EACH ROW
DECLARE
   last_Sequence NUMBER;
   last_InsertID NUMBER;
BEGIN
   SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   IF (:NEW.BRQ_REQUEST_ID IS NULL OR :NEW.BRQ_REQUEST_ID = 0) THEN
      SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   ELSE
      SELECT NVL(Last_Number, 0) INTO last_Sequence
        FROM User_Sequences
       WHERE Sequence_Name = 'BVS_REQUEST_BRQ_REQUEST_ID_SEQ';
      SELECT :NEW.BRQ_REQUEST_ID INTO last_InsertID FROM DUAL;
      WHILE (last_InsertID > last_Sequence) LOOP
         SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO last_Sequence FROM DUAL;
      END LOOP;
   END IF;
END;


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

Eugene Morgan Can it be that you tried to execute the sequence of statement as ONE statement in your client? Because the SQL output you gave here are several statements that normally get execute after each other (each as a single statement):

1.

CREATE TABLE bvs_request (brq_request_id NUMBER(20) NOT NULL, brq_policy_num VARCHAR2(25) NOT NULL, brq_request_date TIMESTAMP(0) DEFAULT CURRENT_TIMESTAMP NOT NULL, PRIMARY KEY(brq_request_id))

2.

DECLARE
  constraints_Count NUMBER;
BEGIN
  SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'BVS_REQUEST' AND CONSTRAINT_TYPE = 'P';
  IF constraints_Count = 0 OR constraints_Count = '' THEN
    EXECUTE IMMEDIATE 'ALTER TABLE BVS_REQUEST ADD CONSTRAINT BVS_REQUEST_AI_PK PRIMARY KEY (BRQ_REQUEST_ID)';
  END IF;
END;

3.

CREATE SEQUENCE BVS_REQUEST_BRQ_REQUEST_ID_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1

4.

CREATE TRIGGER BVS_REQUEST_AI_PK
   BEFORE INSERT
   ON BVS_REQUEST
   FOR EACH ROW
DECLARE
   last_Sequence NUMBER;
   last_InsertID NUMBER;
BEGIN
   SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   IF (:NEW.BRQ_REQUEST_ID IS NULL OR :NEW.BRQ_REQUEST_ID = 0) THEN
      SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO :NEW.BRQ_REQUEST_ID FROM DUAL;
   ELSE
      SELECT NVL(Last_Number, 0) INTO last_Sequence
        FROM User_Sequences
       WHERE Sequence_Name = 'BVS_REQUEST_BRQ_REQUEST_ID_SEQ';
      SELECT :NEW.BRQ_REQUEST_ID INTO last_InsertID FROM DUAL;
      WHILE (last_InsertID > last_Sequence) LOOP
         SELECT BVS_REQUEST_BRQ_REQUEST_ID_SEQ.NEXTVAL INTO last_Sequence FROM DUAL;
      END LOOP;
   END IF;
END;

When executing all statements at once, there are some missing ";" terminators (for example after the first CREATE TABLE statement). This is why Oracle complains about syntax.

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

This is no bug, but a user error.





[DBAL-701] [GH-442] Fixed renaming of MSSQL columns Created: 09/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
is duplicated by DBAL-728 [GH-462] Fix full qualified table nam... Resolved

 Description   

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

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

Message:

When attempting to rename a column on a table that exists in multiple
schemas, it would previously fail.

Checking if a schema name is specified, and JOINing the sys.schemas
catalog view to only return column information about the correct table



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

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

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

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





[DBAL-696] [GH-438] Fix string quoting for OCI8 driver Created: 04/Dec/13  Updated: 20/Dec/13  Resolved: 20/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 skolodyazhnyy:

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

Message:

The Oracle database doesn't require escaping \ between single quotes, so if you pass 'A
B' into query it will be stored with double slash. I have remove \ from the list of the symbols which need to be escaped.



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

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





[DBAL-698] [GH-440] Changed scope of getFullQualifiedAssetName() from private to protected t... Created: 05/Dec/13  Updated: 20/Dec/13  Resolved: 20/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

...o promote extension

During a retrofit of Doctrine DBAL to a legacy DB it was necessary to abstract away from the core Schema class to allow de-normalisation of asset names.



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

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





[DBAL-694] Extend AbstractSchemaManager::dropTable() signature Created: 29/Nov/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

Type: Improvement Priority: Major
Reporter: Nikolay Konev Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

For now, dropTable($tableName) doesn't take into account useful IF EXISTS flag.

I can submit PR with myself if this proposal will be accepted.



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

Nikolay Konev can you please give some information of what you want to achieve with this addition? There are several problems I see here:

1. I am quite sure a method signature changes are not possible here because of BC break (affects AbstractSchemaManager::dropTable and AbstractPlatform::getDropTableSQL).
2. IF EXISTS clauses are not supported on all platforms and not SQL standard AFAIK.

Possible solutions depending on what you want to do:
1. If you just want to make sure that the DROP statement does not fail because of non-existence in DB you can use AbstractSchemaManager::tryMethod('dropTable', 'table_name_here') which tries to drop the table but does not throw an exception if it failed. Drawbacks here are that other errors besides non-existence are silenced, too and you cannot evaluate if it really got deleted at database side.
2. Use AbstractSchemaManager::dropTable() and catch Doctrine\DBAL\DBALException. Check for the error code with DBALException::getCode() and evaluate it to the DBALException::ERROR_UNKNOWN_TABLE constant (currently only available in master branch and available in 2.5 when released - see https://github.com/doctrine/dbal/pull/364).
3. Use AbstractSchemaManager::tableExists method to check if the table exists before calling AbstractSchemaManager::dropTable

You see there are lots of possibilities already and I am not quite sure if we should bloat the schema manager API with more alias methods (drop*IfExists, create*IfNotExists) that actually don't do anything special.

Comment by Nikolay Konev [ 29/Dec/13 ]

Thanks, while i used to wait for answer, i took solution #3 for iExists functionality purposes (test suite setUp & tearDown clean-ups).

And also thanks for DBALException::ERROR_UNKNOWN_TABLE hint — it solves problem finally, without API changes.

Comment by Nikolay Konev [ 29/Dec/13 ]

Found some workarounds, which worth to be documented

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

Nikolay Konev The DBALException error constants are pretty new and need indeed documentation. I will provide that during the next days. Also these exception error codes are converted into an own exception class on the fly (see: https://github.com/doctrine/dbal/pull/458). Not all DBALException::ERROR_* constants will get converted at this time though. Some are still missing but will be added soon. Then you are able to do something like this:

// Schema manager.

try {
    $sm->dropTable('mytable');
} catch (\Doctrine\DBAL\Excpetion\TableNotFoundException $e) { // exception class not yet available
    // do something
}

Besides that do you think there is still anything to do here? Or are those solutions acceptable for you?

Comment by Nikolay Konev [ 29/Dec/13 ]

Solution with tableExists() check is acceptable in my scenario, although it adds some db overhead in my tests.

Issue does not have sense now.





[DBAL-693] Schema migration issue then column changes. Created: 29/Nov/13  Updated: 22/Dec/13  Resolved: 22/Dec/13

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

Type: Bug Priority: Major
Reporter: Maksim Muruev Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: shemamanager
Environment:

ubuntu linux, mysql



 Description   

Migration rise an error then trying ALTER table. Seems like an order problem. Second re-run migration always fix issue. Happens then changes columns in the table.

        /** @noinspection PhpUndefinedMethodInspection */
        $schemaManager = $db->getSchemaManager();
        /** @noinspection PhpUndefinedMethodInspection */
        $fromSchema = $schemaManager->createSchema();
        /** @noinspection PhpUndefinedMethodInspection */
        $sql = $fromSchema->getMigrateToSql($schema, $db->getDatabasePlatform());
        foreach ($sql as $request) {
            /** @noinspection PhpUndefinedMethodInspection */
            $db->executeUpdate($request);
        }

Rise error looks like

 An exception occurred while executing 'ALTER TABLE error CHANGE time time TIMESTAMP DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP':

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mydb.error' doesn't exist


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

This is not enough information, i need the schema from the database and the local schema that helps me to reproduce this error. With this information i cannot reproduce this. Please provide feedback.

Comment by Maksim Muruev [ 16/Dec/13 ]

I've found there problem is. Seems like SchemaManager unable undertand '<db_name>.<table_name> format as table name for createTable() method. After use just table name issue disappears.





[DBAL-695] [GH-437] Don't generate foreign keys for MySQL tables that are not InnoDB Created: 30/Nov/13  Updated: 20/Dec/13  Resolved: 18/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: Won't Fix Votes: 1
Labels: None


 Description   

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

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

Message:

This PR adds a `supportsForeignKeyConstraintBetween($table1, $table2)` method to `Platform` allowing to check if foreign key between two tables are supported (e.g. on MySQL: InnoDB to InnoDB FK is OK, Memory to InnoFB is not).

The MySQL implementation is also provided and `CreateSchemaSqlCollector` has been adapted to use this feature.

This PR is related to https://github.com/doctrine/doctrine2/pull/865



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

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-690] [GH-434] Fix row count retrieval for SELECT statements in SQL Anywhere driver Created: 27/Nov/13  Updated: 18/Dec/13  Resolved: 18/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: Won't Fix 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/434

Message:

The SQL Anywhere driver always tries to return the affected rows when calling `SQLAnywhereStatement::rowCount()`. This is okay for DML statments but always returns `0` for SELECT statements. This patch enables retrieving num rows for SELECT statements.
Also added a test that applies to all driver to ensure that they are all able to return the num rows of the resultset.



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

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





[DBAL-689] [GH-433] Fix binding LOB values in mysqli driver prepared statement Created: 27/Nov/13  Updated: 13/Dec/13  Resolved: 13/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/433

Message:

Running the DBAL test suite with mysqli driver I get a memory exhaustion in `BlobTest`. This is caused by the `MysqliStatement` trying to bind a LOB value before having stored the result set. According to [this comment](http://php.net/manual/en/mysqli-stmt.bind-result.php#57564) in the PHP docs this is necessary when dealing with LOBs. At least this solves the problem for me.



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

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





[DBAL-688] [GH-432] Fix mysqli driver options Created: 27/Nov/13  Updated: 27/Nov/13  Resolved: 27/Nov/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
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/432

Message:

Some mysqli driver options have to be set before actually performing a database connect. `MYSQLI_OPT_LOCAL_INFILE` for example needs to be set before connect and cannot be changed afterwards. I encountered this issue today while trying to perform a `LOAD DATA local INFILE` statement with this driver. Setting the driver options before connect solved the issue.
I wanted to add a test for this but to be honest I have no idea how to test that the driver options are set before connect as both actions happen during construction of the mysqli connection instance.



 Comments   
Comment by Doctrine Bot [ 27/Nov/13 ]

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

Comment by Marco Pivetta [ 27/Nov/13 ]

Merged: https://github.com/doctrine/dbal/commit/4b74a50ff185948b3580865d1879b601bff3c26c





[DBAL-681] [GH-429] Fix some more CS Created: 25/Nov/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/429

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/89c7b527c70d7a12bfdb41c0e88e4ac25e966b6d





[DBAL-680] [GH-428] [DBAL-563] Add interface for sequence emulated identity platforms Created: 25/Nov/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: 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/428

Message:

Currently identity columns on Oracle are implemented with a [trigger and sequence workaround](https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/OraclePlatform.php#L431) to be compatible with IDENTITY generator strategy in ORM. However, using this strategy, the last insert ID is never returned when persisting, as the sequence name generated by DBAL [is not passed to the ID-Generator instance in ORM](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L450) and thus [not passed to the driver](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Id/IdentityGenerator.php#L55) when calling `IdentityGenerator::generate()`. Therefore the Oracle driver always returns null in this case. This makes this strategy unusable.
A similar case is given in PostgreSQL where `SERIAL` identity columns need a sequence in order to work. There is a [hackish implementation](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L453) available in ORM for this case which makes it work.
It is possible that other vendors (when implemented) encounter the same issue. For this reason I tried to create a general solution with this PR.
ORM needs to know which platforms do not have native support for identity columns but can emulate them with sequences. To prepare this I added an interface that identifies a platform being able to do so. Platforms implementing this interface have to return the name of the sequence used for an identity column in a table. ORM can later make use of this and pass it to the `IdentityGenerator` so that the underlying driver in return is able to supply the last insert ID.
Current implementing platforms are PostgreSQL and Oracle.



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

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





[DBAL-684] [GH-431] [DBAL-683] Fix link to known vendor issues in documentation Created: 26/Nov/13  Updated: 17/Dec/13  Resolved: 17/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/431

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/439e33a9ce6a5694ca4277562ba286e19ec40483





[DBAL-692] [GH-436] phpdoc in Table::addForeignKey() update Created: 29/Nov/13  Updated: 13/Dec/13  Resolved: 13/Dec/13

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

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


 Description   

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

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

Message:

Added significant typehint in PhpDoc: `$foreignTable` param in `addForeignKeyConstraint()` can be just string name of table.

It unobvious in IDE hinting and treated as wrong param. It even can confuse developer, forcing him use foreign keys additions only using existing tables. That was my case, for example :confused: Lost time till found out, that Table schema not necessary to exist for Foreign Key referring .



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

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





[DBAL-691] [GH-435] [DBAL-400] Fix adding primary key during table alteration in MySQL Created: 27/Nov/13  Updated: 20/Dec/13  Resolved: 28/Nov/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: Guilherme Blanco
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/435

Message:

This fixes a table alteration scenario in MySQL where a table currently has no primary key and is altered to add a primary key. This currently fails as there is no check whether the index to create is a primary key. Instead a UNIQUE INDEX is scheduled to be created and results in a syntax error.



 Comments   
Comment by Doctrine Bot [ 28/Nov/13 ]

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

Comment by Guilherme Blanco [ 28/Nov/13 ]

Merged: https://github.com/doctrine/dbal/commit/8b28a9a1d1dfafb7cb973bb0bacf057d097885aa





[DBAL-682] [GH-430] [DBAL-464] Fix dropping primary key with autoincrement column in MySQL Created: 25/Nov/13  Updated: 18/Dec/13  Resolved: 18/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/430

Message:

This PR fixes a table alteration scenario in MySQL, where a primary key is to be dropped that contains an autoincrement column. MySQL requires the autoincrement column attribute to be removed first before dropping the primary key. Otherwise the table alteration will fail.



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

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





[DBAL-678] [GH-426] [DBAL-569] Add support for column comments / commented types in SQL Server Created: 24/Nov/13  Updated: 18/Dec/13  Resolved: 18/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/426

Message:

SQL Server has no native support for column comments. Therefore commented types are currently not supported for SQL Server leading to repeated ALTER TABLE statements by schema tool when using types that require column comments.
However there is a way to store column comments. Using SQL Server's extended properties functionality, it is possible to store metadata for columns. This is also the way SQL Server Management Studio stores "Description" property for columns.
This PR implements this to be able to use comments for columns and enable support for commented types.

The PR is not 100% finished, yet as we need to find a way to generate the correct statements in the following table alteration scenarios:

  • Renamed column that also requires a comment change (either due to changed comment or change from or to a commented type that required/requires a column comment change.
  • Changed column where `$columnDiff->fromColumn` is not set.

Using extended properties we need to know whether a column comment has to be added, updated or removed in order to generate the appropriate SQL statement. This is due to SQL Server having a different stored procedure for each operation. Using the wrong stored procedure leads to an error.
Therefore we always need to know the type and comment information from the column to change from in a table alteration scenario. Unfortunately we don't have that if a column is marked as renamed in the table diff or if it is marked as changed but no `$columnDiff->fromColumn` is set (this is the case in some tests actually).

Awaiting feedback how to proceed in thos scenarios.



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

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





[DBAL-679] [GH-427] Save one columns iteration in Comparator::diffTable Created: 24/Nov/13  Updated: 17/Dec/13  Resolved: 17/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/427

Message:

Saves one unnecessary iteration over table columns while diffing two table in the comparator.



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

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

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

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





[DBAL-676] [GH-423] Improve driver exception code conversion Created: 21/Nov/13  Updated: 18/Dec/13  Resolved: 18/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/423

Message:

Drivers should match unique driver-specific error codes instead of substrings in error messages where possible. This PR replaces most of the error string matching. Additionally many more error codes are were added to MySQL.



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

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





[DBAL-677] [GH-425] [DBAL-543] Fix OCI8 TNS connect descriptor / Add pooled option to PDO_ORACLE Created: 21/Nov/13  Updated: 18/Dec/13  Resolved: 18/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/425

Message:

This fixes the syntax of the TNS connect descriptor pooling option in OCI8 driver and also adds pooling option to PDO_ORACLE driver.



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

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





[DBAL-675] [GH-422] Fixed mysql unknown host exceptions for maxosx (freeBSD ?) Created: 21/Nov/13  Updated: 17/Dec/13  Resolved: 17/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: Steve Müller
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

Is this a issue for other os driver/os platforms aswell ?



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

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

Comment by Marco Pivetta [ 17/Dec/13 ]

Duplicate of DBAL-676





[DBAL-674] [GH-421] [DDC-2802] Fix unsupported MySQL index column sizes Created: 20/Nov/13  Updated: 22/Dec/13  Resolved: 22/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Extends Index constructor with `array $options` for any possible index modifications.

For example, Oracle have a _very huge_ list of [index tuning options](http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_5011.htm#SQLRF53870).



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

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





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

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

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


 Description   

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

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

Message:

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



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

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





[DBAL-672] [GH-419] Fix DDC-2802 Created: 19/Nov/13  Updated: 20/Dec/13  Resolved: 20/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Enables specifying MySQL index size on modifying (critical for `TEXT/BLOB` foreign keys):

~~~php
$index = new \Doctrine\DBAL\Schema\Index('my_idx', array('user_name(12)', 'last_login(34)'));
~~~

this will produce

~~~SQL
CREATE INDEX my_idx ON mytable (user_name(12), last_login(34));
~~~



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

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





[DBAL-671] [GH-418] Removed "_" prefix from private and protected attributes. Created: 19/Nov/13  Updated: 26/Nov/13  Resolved: 26/Nov/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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 19/Nov/13 ]

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

Comment by Marco Pivetta [ 26/Nov/13 ]

Fixes will be delayed to 3.x





[DBAL-670] [GH-417] Implement ExceptionConverterDriver for drizzle_pdo_mysql Created: 19/Nov/13  Updated: 18/Dec/13  Resolved: 18/Dec/13

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

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


 Description   

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

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

Message:



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

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





[DBAL-668] [GH-416] Small cleanups, simplification and removed no longer needed cast Created: 14/Nov/13  Updated: 15/Nov/13  Resolved: 15/Nov/13

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

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


 Description   

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

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

Message:

Removed some of the parameter bookkeeping.
Removed apparently no longer needed cast to string. What changed with types ?
The tests runs a few seconds faster on my laptop.
Tested with the ORM.



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

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





[DBAL-666] [GH-414] Enhancement: expose ping() on pingable-connections. Created: 14/Nov/13  Updated: 15/Nov/13  Resolved: 15/Nov/13

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

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


 Description   

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

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

Message:

This PR introduces a new PingableConnection interface and exposes
a ping method on \Doctrine\DBAL\Connection. For drivers where no
ping is supported, a \Doctrine\DBAL\ConnectionException is thrown.



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

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





[DBAL-667] [GH-415] Skip unsupported tests on SQL Anywhere Created: 14/Nov/13  Updated: 14/Nov/13  Resolved: 14/Nov/13

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

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


 Description