[DBAL-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 18/Apr/14

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

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


 Description   

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

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

Message:

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

This makes the following changes to `Connection`:

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

The new way of dealing with transactions is then:

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

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

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

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

I'm looking forward to hearing what you think!






[DBAL-872] [GH-570] Add support for out cursor in OCI8 Created: 18/Apr/14  Updated: 18/Apr/14

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

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


 Description   

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

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

Message:

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






[DBAL-871] [GH-569] Fixed type and initialization value of $_nestTransactionsWithSavepoints Created: 17/Apr/14  Updated: 18/Apr/14  Resolved: 18/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

`Connection::$_nestTransactionsWithSavepoints` is definitely a `boolean` and not an `integer`, and the rest of the code assumes it's `false` by default, whereas it's actually `null` right now. Which still works as `null` evaluates as `false`, but is not clean.



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

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got merged





[DBAL-870] [GH-568] Removed unused imports and unnecessary FQCN Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 17/Apr/14 ]

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





[DBAL-869] [GH-567] Fixed Configuration::getSQLLogger() return type Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

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


 Description   

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

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

Message:

`getSQLLogger()` can return `null`, this was omitted.



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

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

Comment by Marco Pivetta [ 17/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/32c5a3ea7060d8f3edd29907fd324433ea265996





[DBAL-438] [GH-266] Removed outdated methods in DatabasePlatformMock. Created: 03/Feb/13  Updated: 17/Apr/14  Resolved: 05/Feb/13

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

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


 Description   

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

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

Message:

Same as https://github.com/doctrine/doctrine2/pull/567



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

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

Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

Merged : https://github.com/doctrine/dbal/commit/2a58ac0e15315b785f3ee5edb822dc5e45d154d7

Comment by Doctrine Bot [ 23/Dec/13 ]

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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





[DBAL-164] Quoting allows SQL injections Created: 10/Sep/11  Updated: 17/Apr/14  Resolved: 13/Sep/11

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

Type: Bug Priority: Major
Reporter: Oliver Mueller Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

OCI8 Driver
IBMDB" Driver



 Description   

$test = "foo ' bar";
$quoted = $conn->quote( $test );
echo $quoted;

RESULT: 'foo ' bar'
EXPECTED: 'foo \' bar'



 Comments   
Comment by Guilherme Blanco [ 13/Sep/11 ]

Fixed in https://github.com/doctrine/dbal/commit/82cc921447fde697bf3d9f5285d0f0b8587303d8

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Backported to 2.0.9

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Fix was modified to use the Zend Framework code for quoting OCI input: https://github.com/doctrine/dbal/commit/97638edc0fef0e08ce7db631eb130fde950844d7

This code is now in DBAL 2.1.4 and 2.0.9 and i have added some tests to very some simple SQL Injection vectors don't work on any supported platform.





[DBAL-214] Unable to use PDO::FETCH_CLASS with a call to fetch() Created: 30/Jan/12  Updated: 17/Apr/14  Resolved: 05/May/12

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.0.6, 2.0.7, 2.0.8, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.5, 2.1.6, 2.2-BETA1, 2.2-BETA2, 2.2-RC1/RC2, 2.2.0-RC3, 2.2, 2.2.1, 2.2.2, 2.3, 2.5
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Andy Leon Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

EDITED: 2nd attempt to describe this - first one was confusing.

I don't understand why the setFetchMode() method of Doctrine\DBAL\Driver\PDOStatement drops any arguments passed to it. It means that PDO::FETCH_CLASS cannot be used with calls to fetch() and no warning is given until the point when the underlying \PDOStatement complains that no class has been specified.



 Comments   
Comment by Antoine Froger [ 03/Feb/12 ]

In Doctrine/DBAL/Statement.php the 2nd and 3rd arguments of setFetchMode are dropped too.

Error message example when PDO::FETCH_CLASS is used as the first argument of setFetchMode:
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE, 'ClassName');
display the error: PDOException: SQLSTATE[HY000]: General error: fetch mode requires the classname argument

Comment by Fabien Potencier [ 05/May/12 ]

This regression was introduced here: https://github.com/doctrine/dbal/commit/f4acc79a3e91059a932d7a2d43309f6f8f65fa59

It breaks some of my websites when upgrading DBAL. So, this is not an improvement but a regression bug.

Comment by Benjamin Eberlei [ 05/May/12 ]

Yes, i have to change this again.

The problem is its complex to support the 2nd/3rd arguments in the statement caching layer, i will just throw an exception for now and add an improvement ticket.

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed

Comment by Benjamin Eberlei [ 05/May/12 ]

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





[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-257] OCI8Statement::fetchColumn() returns null instead of false Created: 16/Apr/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

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


 Description   

In
public function fetchColumn($columnIndex = 0)
{
$row = oci_fetch_array($this->_sth, OCI_NUM | OCI_RETURN_NULLS | OCI_RETURN_LOBS);
return $row[$columnIndex];
}

there is no control on oci_fetch_array_() returned value.
When it returns false fetchColumn() returns null instead of false.

Solution:
public function fetchColumn($columnIndex = 0)
{
$row = oci_fetch_array($this->_sth, OCI_NUM | OCI_RETURN_NULLS | OCI_RETURN_LOBS);
return isset($row[$columnIndex]) ? $row[$columnIndex] : false;
}



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

Fixed





[DBAL-263] [GH-137] Support OCI8 statements crossing transactions [DBAL-202] Created: 28/Apr/12  Updated: 17/Apr/14  Resolved: 05/May/12

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


 Description   

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

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

Message:

Bug Fix: yes
Feature addition: no
Backwards compatibility break: no
[![Build Status](https://secure.travis-ci.org/dpb587/dbal.png?branch=ticket-dbal-202)](http://travis-ci.org/dpb587/dbal)

Scenario is documented in JIRA DBAL-202(http://www.doctrine-project.org/jira/browse/DBAL-202). Basically in oci8 if you prepare a statement outside of a transaction, start a transaction, execute the statement, rollback the transaction - the statement will still have been executed. Whether it's the correct behavior or not, it seems like it should match PDO's behavior.

This implementation affects the API, so it should probably be carefully reviewed.

A separate test script is available at https://gist.github.com/2515100(gist.github.com/2515100).

$ php -v ; php --re oci8 | head -1
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Extension [ <persistent> extension #52 oci8 version 1.4.2 ] {
$ phpunit -c oci8.phpunit.xml.dist tests/Doctrine/Tests/DBAL/Driver/OCI8/OCI8StatementTest.php
PHPUnit 3.5.13 by Sebastian Bergmann.

..

Time: 0 seconds, Memory: 7.50Mb

OK (2 tests, 2 assertions)
$ phpunit -c oci8.phpunit.xml.dist tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL202Test.php
PHPUnit 3.5.13 by Sebastian Bergmann.

..

Time: 7 seconds, Memory: 9.50Mb
OK (2 tests, 6 assertions)

I had to drop the the following tests to run through the oracle test suite (seemed like my test user didn't have enough permissions for the temp db tests), but all other tests pass.

$ rm tests/Doctrine/Tests/DBAL/Functional/TemporaryTableTest.php
$ rm tests/Doctrine/Tests/DBAL/Functional/TableGeneratorTest.php # see pull 136
$ rm tests/Doctrine/Tests/DBAL/Functional/Schema/OracleSchemaManagerTest.php
$ phpunit -c oci8.phpunit.xml.dist
PHPUnit 3.5.13 by Sebastian Bergmann.

............................................................... 63 / 747 ( 8%)
.......SSSS.....S........S......................S...........S.. 126 / 747 ( 16%)
.............................SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 189 / 747 ( 25%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 252 / 747 ( 33%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.............S........ 315 / 747 ( 42%)
...S...S...SSS................................................. 378 / 747 ( 50%)
............................................................... 441 / 747 ( 59%)
.....SSS....................................................... 504 / 747 ( 67%)
............................................................... 567 / 747 ( 75%)
..............S................................................ 630 / 747 ( 84%)
............................................................... 693 / 747 ( 92%)
......................................................

Time: 33 seconds, Memory: 46.00Mb

OK, but incomplete or skipped tests!
Tests: 747, Assertions: 1145, Skipped: 156.



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

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

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed





[DBAL-387] [GH-230] Fixed SQL Server Platform NULL declaration Created: 21/Nov/12  Updated: 17/Apr/14  Resolved: 25/Nov/12

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

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


 Description   

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

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

Message:

Per previous pull request but based on master. SQL server does not use 'DEFAULT NULL' for marking columns as nullable, only 'NULL'.



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

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





[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-202] Preparing Statements outside Transaction Created: 15/Jan/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

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


 Description   

From the mailing list:

I'm using DBAL 2.1 with Oracle and it appears that if I call prepare() for my SQL and cache the prepared statement for later, if I then start a new transaction and call execute() on the statement, it commits the transaction. Is this behavior intentional? If so, does that mean I have to prepare my statement anew for every transaction?

Note that I'm seeing the aforementioned behavior with code as basic as the following:

$stmt = $dbh->prepare("INSERT INTO test_table (id, description) VALUES
(:my_id, :my_desc)");
$dbh->beginTransaction();
$stmt->execute(array(":my_id" => 1, ":my_desc" => "test"));
$dbh->rollBack();

After executing the above, a record has been committed to the db. If I had a more complex scenario involving a transaction with multiple statements where the entire transaction is inside a loop, this becomes problematic--I can't then prepare my statements outside the loop to improve performance.

When I try the same thing using straight PDO, it works fine. Can anyone else confirm this behavior?



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

Are you using PDO_OCI or oci8 with Doctrine?

Comment by Danny Berger [ 15/Jan/12 ]

I had responded to him on our intranet and intended to submit a patch, but haven't yet found the time to prepare and test one. As a temporary workaround I suggested he prepare the statement inside the transaction. We are using oci8 and the following was my response and analysis:

When the doctrine2 oci8 driver prepares a statement, the generated statement will forever use the active execute mode, regardless of the mode when it's actually executed. I disagree with the current behavior.

As you noted, this is not the behavior used by PDO OCI. Short-term, I think you should prepare the statement inside a transaction. Long-term, I think we should submit a patch to doctrine2, something like follows:

  • add a `getExecuteMode` to `OCI8Connection`
  • add a `getDriverOptions` to `OCI8Connection`
  • remove the `$executeMode` parameter from `OCI8Statement::__construct`
  • remove the `$driverOptions` parameter from `OCI8Statement::__construct`
  • store a reference to `$dbh` to `$this->dbh` from `OCI8Statement::_construct`
  • replace `$this->_executeMode` with `$this->_dbh->getExecuteMode()`
  • replace `$this->_driverOptions` with `$this->_dbh->getDriverOptions()`
Comment by Danny Berger [ 28/Apr/12 ]

Created an independent test - https://gist.github.com/2515100
Submitted a pull request - https://github.com/doctrine/dbal/pull/137





[DBAL-254] SQL Server rename table should use sp_RENAME Created: 11/Apr/12  Updated: 17/Apr/14  Resolved: 08/Jul/12

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

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

SQL Server 2008 R2 on windows Server



 Description   

Whenever DBAL Schema Manager tries to rename a table in sql server 2008 it should use also the sp_RENAME procedure. Otherwise error is thrown.

Apparently a similar issue was fixed for column ALTER Commands as described in the link below, but also the ALTER TABLE command should use sp_RENAME to avoid crash.

http://www.doctrine-project.org/jira/browse/DBAL-199?page=com.atlassian.jira.plugin.system.issuetabpanels%3Achangehistory-tabpanel

Suggested fix for Latest DBAL 2.2

From Line 283:

$queryParts[] = 'RENAME TO ' . $diff->newName;

To Line 283:

$sql[] = 'sp_RENAME \'' . $diff->name . '\',\'' . $diff->newName.'\'';

This seems to fix the problem.

Hope this helps

Sorry for my bad english.

Fredcallagan



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

Fixed.





[DBAL-255] On SQL SERVER Trying to drop a column throws error because of auto generated Constraints Created: 13/Apr/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

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

MS SQL Server + Windows Server 2008



 Description   

Whenever Doctrine tries to drop a column that has some implicit constraints the system the SQL Native Client throws the message:

The Object 'Name_Of_The_Object' is dependent on column 'Column_To_Drop';

This is probably because columns such as Decimal Numbers have an automatice generated constraint that need to be dropped in order to drop a column.

A possible Solution is to add a platform specific getConstratintForTableSQL that queries the database to get all the constraint for the given column, than override the 'alterTable' method in the SQLServer Schema Manager to first drop the constraint than the columns in question by going and checking all the Columns that needs to be dropped in the TableDiff passed.

Something similar to this but better refactored I guess:

Changes in SQLServerPlatform.php

Add a method similar to this:

    /**
     * This function retrieves the constraints for a given column that is going to be droppped 
     */
    public function getColumnConstraintSQL($table, $column)
    {
        return "SELECT SysObjects.[Name]
                From SysObjects Inner Join (Select [Name],[ID] From SysObjects Where XType = 'U') As Tab
                On Tab.[ID] = Sysobjects.[Parent_Obj] 
                Inner Join sysconstraints On sysconstraints.Constid = Sysobjects.[ID] 
                Inner Join SysColumns Col On Col.[ColID] = sysconstraints.[ColID] And Col.[ID] = Tab.[ID]
                Where Col.[Name] = '$column' and Tab.[Name] = '$table'
                order by Col.[Name]";
    }

Changes on SqlServerChemaManager.php

       /**
	* Override
	*/
	public function alterTable(TableDiff $tableDiff)
	{
		if(count($tableDiff->removedColumns) > 0){
			$constraintsSql = array();
			foreach($tableDiff->removedColumns as $col){
				$constraintsSql[] = $this->_platform->getColumnConstraintSQL($tableDiff->name, $col->oldColumnName);
			}
			$constraintsToDrop = array();
			foreach($constraintsSql as $sql){
				 $constraintsToDrop[] = $this->_conn->execute($sql);
			}
			foreach($constraintsToDrop as $constraint){
				$this->_conn->execute("ALTER TABLE $tableDiff->name DROP CONSTRAINT $constraint");
			}
		}
		return parent::alterTable($tableDiff);
	}

Hope this helps

Thx



 Comments   
Comment by Fryderyk Benigni [ 13/Apr/12 ]

This version of the getColumnConstraintSQL seems better:

       /**
	* Override
	*/
	public function alterTable(TableDiff $tableDiff)
	{
		if(isset($tableDiff->removedColumns) && count($tableDiff->removedColumns) > 0){
			$constraintsSql = array();
			foreach($tableDiff->removedColumns as $col){
				$constraintsSql[] = $this->_platform->getColumnConstraintSQL($tableDiff->name, $col->getName());
			}
			$constraintsToDrop = array();
			foreach($constraintsSql as $sql){
				 $constraintData = $this->_conn->fetchAll($sql);
				 foreach($constraintData as $keyCostr => $costraint){
					$constraintsToDrop[] = $costraint['Name'];
				 }
			}
			
			foreach($constraintsToDrop as $key => $constraint){
				$this->_conn->exec("ALTER TABLE $tableDiff->name DROP CONSTRAINT ".$constraint);
			}
		}
		return parent::alterTable($tableDiff);
	}
Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed formatting

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed.

I had to adjust your SQL a little since "sysconstraints" is deprecated and not exists anymore on SQL Azure for example.





[DBAL-269] [GH-141] Fixed conditional expression Created: 05/May/12  Updated: 17/Apr/14  Resolved: 27/May/12

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


 Description   

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

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

Message:






[DBAL-276] MySQL schema manager should not make assumptions about non-DBAL types Created: 16/May/12  Updated: 17/Apr/14  Resolved: 27/May/12

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

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

Macintosh OS X 10.7.2
Homebrew PHP 5.3.6 (CLI SAPI)
Doctrine DBAL v2.1.6, installed via Symfony2's vendor scripts



 Description   

When using the DBAL MySQL schema manager to create migrations or update the schema directly, it can create conflicts with custom types due to the way it processes some non-DBAL types in _getPortableTableColumnDefinition.

I recently implemented a binary-string type, using the MySQL BINARY/VARBINARY columns (as opposed to blob, which I see has been adopted in 2.2), due to the content for my application always being a 60 byte binary string. Doctrine has been working fine with it, but upon generating my next migration, I discovered that the schema manager wanted to re-set the column's length.
Generated SQL: "ALTER TABLE User CHANGE password password VARBINARY(60) NOT NULL"

It appears that this is caused by lines 138 & 139 of MySqlSchemaManager.php clearing the column's length. There doesn't seem to be any other code pertaining to MySQL and binary/varbinary, so removing these two lines should be safe and save trouble for future users, without causing issues for those who choose to implement it as a blob or similar.



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

Fixed





[DBAL-285] Schema generation fails when primary key is quoted Created: 23/May/12  Updated: 17/Apr/14  Resolved: 04/Jul/12

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

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

Linux (gentoo), PHP 5.3.13, MySQL 5.1.62, Symfony2


Attachments: Text File DBAL_Primary_key_fix.txt    

 Description   

All of our entities are generated with their name quoted with back-ticks, this is to allow RAD.
When Doctrine comes to update the schema it fails to see the primary key is quoted and thus compared an index of PRIMARY(id) to PRIMARY(`id`). Which means it then tries to drop the primary index and recreate it, using a quoted field name.

This fix is to when the primary index is created is to fetch the columns from the table and get their unquoted name, so now when the comparison takes place it looks like this PRIMARY(id) to PRIMARY(id), therefore doesn't register this as a change.



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

Fixed





[DBAL-299] Multiple different interspersed named parameters Created: 06/Jul/12  Updated: 17/Apr/14  Resolved: 07/Jul/12

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

Type: Bug Priority: Major
Reporter: Spinning Top Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3.9-ZS5.6.0, Ubuntu 10.04.4 LTS on VirtualBox 4.1..18 r78361 on Mac OS X version 10.6.8



 Description   

For this code

$sql = <<<SQL
SELECT 1 as id
WHERE (:foo = 2)
AND (:bar = 3)
AND (:foo = 2)
SQL;
$rsm = new \Doctrine\Orm\Query\ResultSetMapping();
$rsm->addScalarResult('id', 'id');

$query = $em->createNativeQuery($sql, $rsm);
$query = $query->setParameters(array('foo' => 2, 'bar' => 3));
$result = $query->getResult();

Generates the SQL in DBAL\Connection\executeQuery

SELECT 1 as id
WHERE (? = 2)
AN?bar = 3)
AND (? = 2)

The problem appears to be in DBAL\SQLParserUtils\expandListParameters.

When replacing the named parameters with ?'s an offset is kept to keep track of where to insert the next parameter. This is done per named parameter (all of :foo is replaced then all :bar, etc). This will calculate the incorrect offset if a named parameter(e.g. :bar) is in between instances of another named parameter (e.g. :foo) (i.e. :bar in the sql "(:foo = 2) AND (:bar =3) AND (:foo = 2)") since the offset will be for the TOTAL number of instances of the named parameter (e.g. -6) not the number of instances that occur before the needed replacement (e.g. -3).

This is where the SQL has "AN?bar = 3)" instead of "AND(3 = 3)" the offset is calculated at -6 instead of the proper -3



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Fixed here: https://github.com/doctrine/dbal/commit/78dbf28923059545b24ba753c112560ad59ca89e





[DBAL-323] [GH-185] Add schema changes for length for postgres Created: 17/Aug/12  Updated: 17/Apr/14  Resolved: 06/Oct/12

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

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


 Description   

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

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

Message:






[DBAL-329] [GH-190] Fix DDC-1978 Created: 26/Aug/12  Updated: 17/Apr/14  Resolved: 29/Aug/12

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


 Description   

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

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

Message:

Fix DDC-1978

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



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

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





[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-581] [GH-359] Fixed OCI8 fetch from statement with PDO::FETCH_NUM mode Created: 19/Aug/13  Updated: 17/Apr/14  Resolved: 08/Sep/13

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

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

Message:

See: https://github.com/doctrine/dbal/commit/d919b50ec9806a0bb1d671039d19bb53bc042c28#L2L39



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

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

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Fixed and merged back to 2.3 and 2.4 release branches.





[DBAL-552] Colon (":") in field name treats like query parameter Created: 25/Jun/13  Updated: 17/Apr/14  Resolved: 29/Dec/13

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

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

MySQL


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

 Description   

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

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

causes DBALException:

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


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

does this work with plain PDO?

Comment by Daniel Bojdo [ 25/Jun/13 ]

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

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

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

Comment by Doctrine Bot [ 29/Dec/13 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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





[DBAL-654] [GH-403] [DBAL-589] Fix type hint in Column::visit() Created: 06/Nov/13  Updated: 17/Apr/14  Resolved: 13/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: 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/403

Message:



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

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





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

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

Message:

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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



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

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





[DBAL-744] [GH-477] [DBAL-552] Fix parsing backtick quoted statement fragments in SQLParserUtils Created: 29/Dec/13  Updated: 17/Apr/14  Resolved: 29/Dec/13

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

Message:

MySQL uses backtick for identifier quotation. The `SQLParserUtils` treats statements with quoted identifiers that contain a colon as named parameter which is wrong.

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

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

This PR adds the backtick character to the recognized quote characters when retrieving unquoted statement fragments.



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

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





[DBAL-760] [GH-490] Don't return warnings as errors in sqlsrv driver Created: 03/Jan/14  Updated: 17/Apr/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/490

Message:

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

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

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



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

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





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

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

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


 Description   

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






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

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

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

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

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



 Description   

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

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

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






[DBAL-828] [GH-538] Json_Array: Convert database null to PHP null instead of empty array Created: 04/Mar/14  Updated: 17/Apr/14

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

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


 Description   

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

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

Message:

Related to https://github.com/doctrine/doctrine2/pull/968.



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

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





[DBAL-868] [GH-566] added support of LOB download Created: 16/Apr/14  Updated: 16/Apr/14

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

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


 Description   

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

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

Message:

OCI8Statement::bindParam() was forcing a LOB upload when passing a
parameter of a LOB type. Also, this forced upload is out of concern for
OCI8Statement::bindParam().

So I removed it to support LOB download. Now call of
oci_new_descriptor() to create a LOB is the responsibility of the
controller. To help this call I added OCI8Connection::getDBH() to be
able to get the resource to the connection.

File download example:
```
$connection = new \Doctrine\DBAL\Connection(...);
$sql = 'BEGIN APP.PKG_NAME.GET_FILE(:id,:data); END;';
$stmt = $connection->prepare($sql);
$stmt->bindValue('id', $id);

$blob = oci_new_descriptor($connection->getWrappedConnection()->getDBH(), OCI_DTYPE_LOB);
$stmt->bindParam('data', $blob, PDO::PARAM_LOB);

$stmt->execute();
$data = $blob->load();
```

File upload example:
```
$connection = new \Doctrine\DBAL\Connection(...);
$sql = 'BEGIN APP.PKG_NAME.PUT_FILE(:id,:bData); END;';
$stmt = $connection->prepare($sql);
$stmt->bindValue('id', $id);

$blob = oci_new_descriptor($connection->getWrappedConnection()->getDBH(), OCI_DTYPE_LOB);
$blob->writeTemporary($data, OCI_TEMP_BLOB);
$stmt->bindParam('data', $blob, PDO::PARAM_LOB);

$stmt->execute();
```






[DBAL-867] Doctrine\DBAL\Driver\Connection should be marked as an internal interface Created: 16/Apr/14  Updated: 16/Apr/14

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

Type: Documentation Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently, the main entry point Doctrine\DBAL\Connection is documented as a wrapper around Doctrine\DBAL\Driver\Connection.
This is very misleading and encourages other library to typehint against Doctrine\DBAL\Driver\Connection rather than Doctrine\DBAL\Connection. See https://github.com/symfony/symfony/pull/10720 for the original discussion.

However, the discussion in https://github.com/doctrine/dbal/pull/414#discussion_r7688765 implies that they should actually not be related together (but it cannot be fixed for BC reasons). The phpdoc should at least be changed






[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-866] Foreign Key Constraints does not work with Doctrine/Symfony and SQLite Created: 12/Apr/14  Updated: 12/Apr/14

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

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

PHP 5.5.9, SQLite3 module version 0.7-dev, SQLite Library 3.8.3.1



 Description   

I have posted a question on stackoverflow already to get help on this issue, but nobody could give me a sufficient answer. See here.

#370 says that support for foreign keys support for SQLite has been implemented. But in my case it does not work. I have defined two entities:

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Category:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    oneToMany:
        ministries:
            targetEntity: Ministry
            cascade: [persist]
            mappedBy: category

And

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Ministry:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    manyToOne:
        category:
            targetEntity: Category
            inversedBy: ministries
            joinColumn:
                name: category_id
                nullable: false
                onDelete: CASCADE

But when I delete a category, the ministry entities do not get deleted, although the constraint should cascade. What am I missing?

Do I have to configure anything to get that working or is it a bug?






[DBAL-864] Failure to insert FALSE into a bool column Created: 10/Apr/14  Updated: 11/Apr/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have experienced this problem with MySQL, I am not sure how it behaves with other platforms. Also, maybe this duplicates http://www.doctrine-project.org/jira/browse/DBAL-630 but since that issue is specifically about PostreSQL I am creating a separate one.

[Doctrine\DBAL\Exception\DriverException]
An exception occurred while executing 'INSERT INTO ACL_Authorization
(role_id, securityIdentity_id, parentAuthorization_id, entity_class, entity_id, cascadable)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'
with params [2, 2, null, "Account\\Domain\\Account", 2, false]:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'cascadable' at row 1

I think it's related to https://bugs.php.net/bug.php?id=49255 (PDO fails to insert boolean FALSE to MySQL in prepared statement) which casts FALSE into an empty string.



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

Matthieu Napoli this issue could need some additional environment information. Also, isn't there a parameter count mismatch?

Comment by Steve Müller [ 10/Apr/14 ]

Yeah the VALUES clause looks weird concerning number of parameters. Could you maybe also provide information of how you constructed the query? DBAL? ORM? A little code snipüpet would help...

Comment by Matthieu Napoli [ 10/Apr/14 ]

I removed useless values to clear up the message, don't mind the excessive "?" in "VALUES".

Here is the code that trigger this: https://github.com/myclabs/ACL/blob/master/src/Repository/AuthorizationRepository.php#L62

More explicitly, this is: $connection->insert($tableName, $data) with $data being a simple array.

We are talking about DBAL (else I would have opened the issue in the ORM project), probably master (my constraint is master of ORM).

Regarding the environment, this is weird: I can't reproduce it on Ubuntu (PHP 5.5, MySQL version I don't know). The bug appears on OS X, PHP 5.5.5, MySQL 5.6.17 (just upgraded).

Comment by Matthieu Napoli [ 10/Apr/14 ]

I confirm that this is related to FALSE being casted to string, when I cast the boolean to an int it works. Example:

$data = [
    // ...
    'cascadable' => (int) $authorization->isCascadable(),
];
Comment by Matthieu Napoli [ 10/Apr/14 ]

And to be extra-sure I tried casting to boolean, but I still get the error:

$data = [
    // ...
    'cascadable' => (bool) $authorization->isCascadable(),
];
Comment by Marco Pivetta [ 11/Apr/14 ]

Matthieu Napoli is this due to a change in the ORM, an upgrade on your side or are were you implementing something in your codebase? I just wanted to be sure if this may be due to a breakage on your side or something you're experiencing on your code changes.

Comment by Matthieu Napoli [ 11/Apr/14 ]

There is nothing "new" on my side except the code (I mean I didn't "upgrade" anything): this is a new project I started.

Since I use embedded objects, I required doctrine/orm dev-master (or 2.5-BETA3 I don't know but it's roughly the same). Then I used DBAL to do a simple insert:

$data = [
    ...
    'cascadable' => $authorization->isCascadable(),
];

$connection->insert($tableName, $data);

The tests for this "ACL" project are run using SQLite in memory, and they always pass (on every machine).

When I use the project (as a dependency) in another one, with a MySQL backend, it works (i.e. no error) on my Ubuntu machine but not on my OS X machine.

I will be trying to reproduce it in a test today, however I am on Ubuntu right now (work) so maybe I won't see it.

(side note: I have no idea what's the deal between the Ubuntu and OS X machine, both have PHP 5.5 and a latest version of MySQL...)

Comment by Matthieu Napoli [ 11/Apr/14 ]

So as I feared, the test I wrote passed on my Ubuntu machine but fails on my Macbook.

Here is the test: https://github.com/mnapoli/dbal/compare/DBAL-864 As you can see it's as simple as it can be.

Exception : [Doctrine\DBAL\Exception\DriverException] An exception occurred while executing 'INSERT INTO dbal864tbl (foo) VALUES (?)' with params [false]:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'foo' at row 1

With queries:
3. SQL: 'INSERT INTO dbal864tbl (foo) VALUES (?)' Params: ''
2. SQL: 'CREATE TABLE dbal864tbl (foo TINYINT(1) NOT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

The test passes with SQLite however…

Comment by Matthieu Napoli [ 11/Apr/14 ]

I am confused by the explanation given in https://bugs.php.net/bug.php?id=49255 but I tend to think it's related. When I run the test in debug and step by step, I confirm that the data passed to PDO is array(false). The casting of false to '' happens inside PDO.

Edit: It's starting to make sense, have a look here: https://bugs.php.net/bug.php?id=33876

The PDO documentation says that PDOStatement::execute says that "All values are treated as PDO::PARAM_STR" (http://php.net/manual/en/pdostatement.execute.php), whereas this should work:

$res->bindValue(1, false, PDO_PARAM_BOOL);
$res->execute();




[DBAL-863] [GH-564] [DBAL-630] Incorrect PostgreSQL boolean handling Created: 04/Apr/14  Updated: 07/Apr/14

Status: Awaiting Feedback
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: boolean, dbal, orm, postgresql


 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.





[DBAL-630] Incorrect PostgreSQL boolean handling Created: 14/Oct/13  Updated: 04/Apr/14

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

Type: Bug Priority: Critical
Reporter: Stan Imbt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

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

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

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

To make this absolutely clear:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

Comment by Benjamin Eberlei [ 01/Jan/14 ]

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

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

Comment by Benjamin Eberlei [ 01/Jan/14 ]

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

Comment by Stan Imbt [ 02/Jan/14 ]

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

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

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

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

Comment by Stan Imbt [ 01/Apr/14 ]

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

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

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

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

<?php

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

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

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

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

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

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

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

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

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

But when it is disabled, it outputs:

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

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

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

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

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

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

$ phpenv shell 5.5.11

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

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

Configuration read from.postgres.phpunit.xml

..F

Time: 3.91 seconds, Memory: 4.25Mb

There was 1 failure:

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

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

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

$ phpenv shell system 

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

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

Configuration read from ./postgres.phpunit.xml

..F

Time: 1.59 seconds, Memory: 4.25Mb

There was 1 failure:

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

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

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

$ phpenv shell 5.3.18 

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

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

Configuration read from ./postgres.phpunit.xml

...

Time: 1.06 seconds, Memory: 6.50Mb

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

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

I'm sorry.





[DBAL-620] [GH-383] SQL Server Paginator bug fix Created: 30/Sep/13  Updated: 04/Apr/14  Resolved: 16/Nov/13

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

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


 Description   

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

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

Message:

This patch solves bug http://www.doctrine-project.org/jira/browse/DDC-2687
and takes inspiration from this PR https://github.com/doctrine/dbal/pull/374 which was written for this bug http://www.doctrine-project.org/jira/browse/DDC-2622



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

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

Comment by Doctrine Bot [ 01/Oct/13 ]

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

Comment by Fabio B. Silva [ 16/Nov/13 ]

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

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DBAL-607] [GH-371] DDC-2662 - SQLServer expects the `OVER` clause to only include columns from the `FROM` clause Created: 15/Sep/13  Updated: 04/Apr/14  Resolved: 15/Sep/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: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

DDC-2622 - SQLServer expects the `OVER` clause to only include columns from the `FROM` clause

As of http://technet.microsoft.com/en-us/library/ms189461.aspx :

`order_by_expression:

> Specifies a column or expression on which to sort. order_by_expression can only refer to columns made available by the FROM clause. An integer cannot be specified to represent a column name or alias.

That basically means that table aliases used to fetch the selected columns should NOT be included in the `OVER` clause.



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

Duplicate of DDC-2622

Comment by Doctrine Bot [ 16/Sep/13 ]

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

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DBAL-610] [GH-374] [WIP] DDC-2622 - SQLServer expects the `OVER` clause to only include columns from the `FROM` clause Created: 16/Sep/13  Updated: 04/Apr/14  Resolved: 16/Sep/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: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

DDC-2622(http://www.doctrine-project.org/jira/browse/DDC-2622) - SQLServer expects the `OVER` clause to only include columns from the `FROM` clause

As of http://technet.microsoft.com/en-us/library/ms189461.aspx :

> `order_by_expression:

> > Specifies a column or expression on which to sort. order_by_expression can only refer to columns made available by the FROM clause. An integer cannot be specified to represent a column name or alias.

That basically means that table aliases used to fetch the selected columns should NOT be included in the `OVER` clause.

This PR is required for doctrine/doctrine2#789



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

Duplicate of DDC-2622

Comment by Doctrine Bot [ 30/Sep/13 ]

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

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DBAL-862] [GH-563] Lower case "order by" keyword causes wrong LIMIT query on SQL Server Created: 02/Apr/14  Updated: 02/Apr/14

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

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


 Description   

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

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

Message:

SQLServerPlatform::modifyLimitQuery('SELECT * FROM user order by username')

(lowercase order by)
returns

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY order) AS doctrine_rownum FROM user order by username) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10

instead of

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY username) AS doctrine_rownum FROM user) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10





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

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

Type: Bug Priority: Major
Reporter: Chris Ramakers Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

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



 Description   

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

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

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

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



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

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

schemaNeedsCreation

seems indeed to be wrong.

Comment by Marco Pivetta [ 13/Dec/13 ]

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

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

Comment by Chris Ramakers [ 02/Apr/14 ]

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





MsSQL-Server DateTime microseconds issue (DBAL-860)

[DBAL-861] ensure the dateformat Y-m-d gets used by the MsSQL-Server 2005 Created: 14/Feb/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Sub-task Priority: Major
Reporter: Martin Weise Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

php5.3.5; MsSQL-Server 2005; W2K8; Apache2; MS pdo_sqlsrv_ts_vc6 driver



 Description   

To ensure that the MsSQL-Server 2005 (and maybe higher) uses the format that is specified in the MsSqlPlatform class (Y-m-d)
set it via 'SET DATEFORMAT ymd' .

This should be done directly after the connection has be opened.



 Comments   
Comment by Martin Weise [ 14/Feb/11 ]

Issue created as wished from Juozas Kaziukenas.

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

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





[DBAL-860] MsSQL-Server DateTime microseconds issue Created: 11/Feb/11  Updated: 01/Apr/14  Resolved: 09/Jan/12

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

Type: Bug Priority: Major
Reporter: Martin Weise Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

WindowsXP/Windows2008 R2 / PHP 5.3 / MsSQL-Server 2005 / MsSQL-PDO_PHP-Driver


Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-861 ensure the dateformat Y-m-d gets used... Sub-task Resolved Benjamin Eberlei  

 Description   

The string for the function getDateTimeFormatString() in the MsSqlPlatform class is 'wrong'.
The Microsoft-SQL-Server just uses 3 digits for microseconds and not 6.
So the string 'Y-m-d H:i:s.u' fails and the server states: [SQL Server]Fehler beim Konvertieren einer Zeichenfolge in einen datetime-Wert (Error when converting a string to a datetime-value) .

So this string works, but does not regard the microseconds for those how rely on them: 'Y-m-d H:i:s.000'

See also:
[...] The MS datetime column is documented to have an accuracy of only about .3 seconds anyway [...]
http://bytes.com/topic/sql-server/answers/80150-inserting-datetime-milliseconds-sql-server

http://msdn.microsoft.com/en-gb/library/ms186819.aspx (Section: Remarks)



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

Assigned to juozas, but i think the issue here is that you have to use Datetime2, or add your own type replacing the shipped one to support the old datetime.

Comment by Martin Weise [ 14/Feb/11 ]

Ok, I had another problem with the datetime, but this does not regard the problem of this issue ( at least not totally).
The problem with the MsSQL-Server before 2008 is that there is no data type named 'datetime2', just 'datetime'.
The next problem is that every date conversion for a query is done in the language set upon conection time.
Thus leads to a problem, when it is not possible to set the connection language.

So the problem is that the MsSQL-Server relies on the settings above.
In my case the datetime conversion failed, as the server always thought that the datetime-string would come in
the following format: Y-d-m . This is not true, as the default format string is: Y-m-d . So every insert/update query fails.
To solve the problem I did that: $entityManager->getConnection()->exec('SET DATEFORMAT ymd'); .
This way I ensured that the dateformat string works fine, except the issue problem.

To solve the problem in general, it would be helpful to subclass the MsSqlPlatform into a class named MsSql2005Platform or something like this and just override the getDateTimeFormatString and upon connection setting the format for the queries
as mentioned before.

Hope this helps out.
Besides, here a link to the datetime problem (in german): http://www.insidesql.org/blogs/frankkalis/2010/08/19/der-ultimative-guide-fuer-die-datetime-datentypen

Comment by Juozas Kaziukenas [ 14/Feb/11 ]

I have somehow manage to miss the fact that datetime2 wasn't around in datetime... What I'm thinking now is there a need for datetime2 in Doctrine at all. If only thing it brings is additional accuracy for microseconds, maybe best idea would be to use datetime for 2008 installs too if used from Doctrine. However datetime is now a standard and Microsoft recommends to use it for new installs. What I can do is I can always insert 3 fractional points to datetime column as both datetime2 and datetime would accept it as valid date string.

We can have separate platforms for 2008 and 2005 servers, but that would be quite resource intensive. Let me see what is the best way to fix it.

Regards to Dateformat, I guess the solution would be to set format on connection, how you suggested. How about you create a separate ticket for this and assign it to me.

Comment by Benjamin Eberlei [ 14/Feb/11 ]

Oracle also has an Session Init Listener that handles the date format things, i guess we can take this as example. However I think having Mssql2005Platform sounds goods also, it would be only one method to override.

Comment by Martin Weise [ 09/Aug/11 ]

To solve this issue, at least for MsSQL-Server datetime data types, change the following TypeClass of Doctrine by adding
this check before converting to PHP\DateTime in 'convertToPHPValue()' :

if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
$value = $value.'000';

I know this is propably very specific, but I do not know, how other DBs handle microseconds in datetime strings.

Comment by Martin Weise [ 08/Sep/11 ]

I fixed this bug with some changes in the DateTimeType class. As there is no Explicit MSSQL2005 Plattform this change would also affect datetime2 type in the SQLServer 2008 plattform, which is the data type that has 6 microseconds.
So either populate a MSSQLServer2005 Plattform, or introduce a new DateTimeType for the 2005 platform.

DateTimeType.php

<?php
/*
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * This software consists of voluntary contributions made by many individuals
 * and is licensed under the LGPL. For more information, see
 * <http://www.doctrine-project.org>.
 */

namespace Doctrine\DBAL\Types;

use Doctrine\DBAL\Platforms\AbstractPlatform;

/**
 * Type that maps an SQL DATETIME/TIMESTAMP to a PHP DateTime object.
 *
 * @since 2.0
 */
class DateTimeType extends Type
{
    public function getName()
    {
        return Type::DATETIME;
    }

    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        return $platform->getDateTimeTypeDeclarationSQL($fieldDeclaration);
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
		if( $value === null)
			return null;

		$value = $value->format($platform->getDateTimeFormatString());

		if( strlen($value) == 26 &&
			$platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u' &&
			$platform instanceof \Doctrine\DBAL\Platforms\MsSqlPlatform )
			$value = substr($value, 0, \strlen($value)-3);

		return $value;

    }

    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        if ($value === null) {
            return null;
        }

		if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
			$value = $value.'000';

        $val = \DateTime::createFromFormat($platform->getDateTimeFormatString(),$value);
        if (!$val) {
            throw ConversionException::conversionFailedFormat($value, $this->getName(), $platform->getDateTimeFormatString());
        }
        return $val;
    }
}

Comment by Benjamin Eberlei [ 09/Jan/12 ]

Added SQLServer2005 platform that uses DATETIME and the .000 format as per instructions of Martin.





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

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved 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.





[DBAL-858] oracle IN statement with more than 1000 values Created: 11/Jan/13  Updated: 01/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Marc Drolet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If I have a query with a IN statement with more tahn 1000 values I get an sql error.

I've try IN with implode:
select * from test where id IN(' . implode(',', $values) . ')
and I've also try with executeQuery:
select * from test where id IN(:test)
executeQuery($sql, array($values), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY))



 Comments   
Comment by Marc Drolet [ 11/Jan/13 ]

Here is the way I've implement the solution on my side: (for oracle)

into Doctrine/DBAL/Statement.php, I've add this method:

/**
     * Binds a parameter value to the statement.
     * This is implemented this way for oracle only. Other drivers are redirected to bindValue method.
     *
     * The value will be bound with to the type provided (that required to be a table type).
     *
     * @param String $name The name or position of the parameter.
     * @param Array $value The value of the parameter.
     * @param String $type The name of the type to use to bind.
     * @return boolean TRUE on success, FALSE on failure.
     */
    public function bindList($name, Array $value, $type)
    {
        if ('oracle' !== $this->platform->getName())
        {
            $this->bindValue($name, $value, $type);
        }
        else
        {
            return $this->stmt->bindList($name, $value, $type);
        }
    }

into Doctrine/DBAL/Driver/Statement.php I've add:

/**
     * @TODO: docs
     */
    function bindList($param, Array $values, $type);

into Doctrine/DBAL/Driver/OCI8/OCI8Statement.php I've add this method:

/**
     * {@inheritdoc}
     */
    public function bindList($param, Array $value, $type)
    {
        if (!($list = oci_new_collection($this->_dbh, $type)))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }

        foreach ($value as $entry)
        {
            $list->append($entry);
        }
        if (!oci_bind_by_name($this->_sth, $param, $list, -1, OCI_B_NTY))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }
    }

// NOTE: we should probably add the bindList to all driver Statement object.

into your code you can use it this way:

$sql = "
    SELECT *
    FROM test
    WHERE id IN
    (
        SELECT *
        FROM
        (
            CAST (: p_ids AS list_int_type)
        )
    )
";
$stmt = connection->prepare($sql);
$stmt->bindList(': p_ids', $ids, 'list_int_type');
$stmt->execute();
$rs = $stmt->fetchAll(PDO::FETCH_ASSOC);

NOTE:
list_int_type need to be a valid oracle data type. You can create one with the name you want.
example:
you can have 2 type of accepted array of values: integer and string
let's say we create one for string named: list_str_type and one for integer list_int_type

create or replace type list_str_type as table of varchar2(4000);
create or replace type list_int_type as table of number;

Comment by Benjamin Eberlei [ 01/Apr/13 ]

Hey Marc Drolet

thanks for the feedback and the solution, however i would like to have something generic that is working independent of the database driver. This code is very specific.

Can you point me to some documentation why oci collection works with more than 1000 elements and how it works in PHP?

Comment by Marc Drolet [ 02/Apr/13 ]

Hi Benjamin,

The limitation is not from the oci driver, it's an oracle limitation. There are a couple of possible solution/implementation that can be done but the one I've provide is the one that perform better for the test I've done and from what I can found over the blogs I've read.

I can't find the exact documentation of oracle. oracle doc is so poor.
Here is the best description link I can provide that describe some possible implementation.
http://vsadilovskiy.wordpress.com/substituting-a-collection-for-in-list-performance-study/

I don't know if there is similar limitation with other database. With the implementation I've provided, It will be possible to implement the proper solution depending on the database limitation you face otherwise it will execute the generic IN. What's bad, we need to create the type into the database.

NOTE: In my case, I can not perform a sub-query, I get the my collection from a web service call.





[DBAL-854] [GH-559] Fix LOCATE expression on SQL Anywhere and SQLite Created: 31/Mar/14  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

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


 Description   

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

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

Message:

This fixes an error in the `LOCATE` expression on SQL Anywhere by using the native `LOCATE` SQL function now, as well as an error with the `LOCATE` expression on SQLite where the offset was evaluated incorrectly.
Also added functional tests to finally verify this stuff.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/0833d00b1c3674b49091221491ba55f00424711c





[DBAL-857] [GH-562] Fix TRIM expression Created: 31/Mar/14  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

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


 Description   

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

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

Message:

The `TRIM` expression is broken on SQL Anywhere and while fixing it and writing functional tests for testing the `TRIM` expression on all platforms, I realized that it is seriously broken in `AbstractPlatform`, too.
We have prove now through the tests that it works as expected.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/3986daf9fa0b18ee1d0f4ec12bacf057b4be5c44





[DBAL-856] [GH-561] Fix FOR UPDATE SQL on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

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

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

Message:

It looks like there was a misunderstanding on SQL Anywhere with the `FOR UPDATE` SQL as this is actually a statement used in prepared statements and does not work the ANSI way in ORM. So I removed it in favour of the table lock hint implementation which works out quite well and makes the `getForUpdateSQL()` rather useless anyways. SQL Server does it like this, too btw and both dialects are pretty similar because SQL Anywhere once drived from it.






[DBAL-855] [GH-560] Fix DateTimeTz type compatibility on SQL Anywhere versions < 12 Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

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

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

Message:

SQL Anywhere versions < 12 do not support a native date time with timezone type. Therefore the fallback strategy is to use the normal date time type. However the format of the date time tz type declaration has to correspond to the normal date time type declaration, too then.

`getDateTimeTzTypeDeclarationSQL()` -> `getDateTimeTypeDeclarationSQL()`
`getDateTimeTzFormatString()` -> `getDateTimeFormatString()`

I thought about changing that in the `AbstractPlatform` but I am not sure if that might break assumptions in userland code and therefore BC. So I left the implementation SQL Anywhere specific.






[DBAL-853] [GH-558] Fix integer 0 default value reverse engineering on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

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

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

Message:

If an integer column was created with a default value of `0`, SQL Anywhere reverse engineers the default value to `null`. This is fixed by this PR.






[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-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-850] [GH-555] Improved performance of BlobType Created: 27/Mar/14  Updated: 27/Mar/14

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

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


 Description   

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

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

Message:

I noticed that the `string` to `resource` conversion code in `BlobType` uses a quite inefficient technique.
This PR improves its performance with a simple change involving the `php://temp` stream.

Quick benchmark of the two approaches, converting a 10MB string:

$value = str_repeat('x', 10 * 1024 * 1024);

$t = microtime(true);
$fp = fopen('data://text/plain;base64,' . base64_encode($value), 'r');
printf("%.3fs\n", microtime(true) - $t);

$t = microtime(true);
$fp = fopen('php://temp', 'rb+');
fwrite($fp, $value);
fseek($fp, 0);
printf("%.3fs\n", microtime(true) - $t);

Results on my laptop:

0.090s
0.008s

A tenfold improvement!






[DBAL-849] [GH-554] Add support string date modifiers for SqlitePlatform Created: 26/Mar/14  Updated: 26/Mar/14

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

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


 Description   

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

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

Message:

In some cases we need support of non-numeric date(datetime) modifiers.
For example if we store interval-value-field in the table. Sqlite doesn't support 'field day' modifier. Common solution for this case is concatenate interval to a string: '' || field || 'day'






[DBAL-843] Doctrine DBAL getSchema() detect wrong text type (LONGTEXT instead of TEXT) Created: 22/Mar/14  Updated: 26/Mar/14

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

Type: Bug Priority: Minor
Reporter: Stefano Kowalke Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I created a database from Doctrine Schema (refer as "expected schema" in the text below) which worked fine. Later I need to compare the "expected schema" with the "current schema" from the database. While I am doing that I figured out the the SQL statements of both schemas differs. While the "expected schema" defines a TEXT type for a field, the "current schema" defines a LONGTEXT for the field.

Here is what I am doing:
$tableName = $schema->createTable('tableName');
$tableName->addColumn('fieldName', 'text', array('length' => 65535, 'notnull' => FALSE));

$currentSchema = $connection->getSchemaManager()->createSchema();
$currentSQL = $currentSchema->toSql($connection->getPlatform());

// CREATE TABLE tableName (fieldName LONGTEXT DEFAULT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

$expectedSchema = $this->getExpectedSchema();
$expectedSQL = $expectedSchema->toSql($connection->getPlatform());
// CREATE TABLE tableName (fieldName TEXT DEFAULT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

This happens because in Doctrine/DBAL/Schema/MySqlSchemaManager.php the type of text is detect correctly but the length is set to FALSE instead of 65535 and when it comes to create the SQL string from the schema it just returns LONGTEXT because the variable $length is FALSE (See Doctrine/DBAL/Platforms/MySqlPlatform::getClobTypeDeclarationSQL().

I added a new case in MySqlSchemaManager::_getPortableTableColumnDefinition which set the length of text types to 65535 and it works. I don't know if this is the correct place in code to do that.

Maybe you can point at the correct place and I will create a PR at Github.



 Comments   
Comment by Steve Müller [ 22/Mar/14 ]

Stefano Kowalke which DBAL version are you using? As far as I can see the length is preserved for text type columns. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L131-L160

Comment by Stefano Kowalke [ 22/Mar/14 ]

But there is no length information inside $tableColumn['type']. While the value of INT type in $tableColumn['type'] is 'int(11)', the value for TEXT type is just 'text'.

The number inside the parentheses is extracted in https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L111 for INT type but not for the TEXT type - line 111 returns and save FALSE in $length.

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

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

Comment by Stefano Kowalke [ 26/Mar/14 ]

Thanks for taking care of this.

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

Thanks for reporting





[DBAL-848] [GH-553] [DBAL-843] Fix reverse engineering LOB type column types in MySQL Created: 25/Mar/14  Updated: 25/Mar/14

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

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


 Description   

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

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

Message:

This PR fixes reverse engineering the length of `TextType` / `BlobType` columns in MySQL which is important for proper SQL generation of distinct native `TINYTEXT`, `TEXT`, `MEDIUMTEXT`, `LONGTEXT`, `TINYBLOB`, `BLOB`, `MEDIUMBLOB` and `LONGBLOB` types.






[DBAL-336] [GH-195] Removed duplicate table check so that ManyToMany relationships can have two owning entities Created: 02/Sep/12  Updated: 25/Mar/14  Resolved: 05/Sep/12

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   

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

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

Message:

Whenever there is a ManyToMany relationship with both entities needing ownership, running doctrine:schema:update throws an exception due to a duplicate table definition when, in fact, it is the same table.



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

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

Comment by Doctrine Bot [ 25/Mar/14 ]

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





[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-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-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-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-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-846] [GH-551] Foreign key checks on MySQL >= 5.5.7 for TRUNCATE Created: 24/Mar/14  Updated: 24/Mar/14

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

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


 Description   

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

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

Message:

  • Added `ConfigurablePlatform` interface to set the connection
    parameters to the Platform
  • Connection is now setting the parameters to the Platform if it
    implements `ConfigurablePlatform`
  • `MySQLPlatform::getTruncateSql()` now checks for a new param
    `disable_fk_checks`, if it is true and the version is affected, it
    automatically adds the required SQL.

Additional solution to https://github.com/doctrine/dbal/pull/549






[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-233] Signed / unsigned types are ignored by Comparator for MySQL schemas Created: 08/Mar/12  Updated: 22/Mar/14  Resolved: 14/Mar/12

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

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

MySQL 5.5



 Description   

E.g. one schema has an column1 which is unsigned tinyint, another schema doesn't.
The sql that is generated is the following:

ALTER TABLE table1 ADD column1 TINYINT(1) NOT NULL DEFAULT '1'

And it should be:

ALTER TABLE table1 ADD column1 TINYINT(1) UNSIGNED NOT NULL DEFAULT '1'

If in one schema there is an unsigned column and in the other it is signed (that being the only difference), the difference is not noticed at all.



 Comments   
Comment by Artem Goutsoul [ 08/Mar/12 ]

Fixed typo in the issue name

Comment by Benjamin Eberlei [ 14/Mar/12 ]

Due to the infinite amount of datatypes and their special options we cannot support everything in Doctrine DBAL Schema. Since signed/unsigned is not a part of the Doctrine ORM API we also do not support it in the DBAL. There are extension hooks which make this available to you, if you want to extend Doctrine in that regard.

See \Doctrine\DBAL\Schema\Column#getCustomSchemaOptions() and how Doctrine\DBAL\Schema\Comparator::diffColumn() uses them. You can fill these fields from events that are fired inside \Doctrine\DBAL\Schema\MySQLSchemaManager.

Comment by Artem Goutsoul [ 15/Mar/12 ]

Thank you for your answer! and for the info of where to look, I'll try to extend the DBAL myself.
It just seemed based on the site and the docs that DBAL could be used as a more general purpose DBAL without the Doctrine ORM. Seems like a robust PHP based schema sync is an unattainable holy grail

Comment by Artem Goutsoul [ 15/Mar/12 ]

I studied the code, and it seems that there is already support for UNSIGNED in the data structures and comparison logic, however, it is simply not picked up from the column type and not saved.

I added the following code to MySqlSchemaManager::_getPortableTableColumnDefinition($tableColumn):

if (strpos(strtolower($tableColumn['type']), 'unsigned') !== false) $unsigned = 'unsigned';

and the replacing the following code to AbstractPlatfrom::getColumnDeclarationSQL($name, array $field)

$columnDef = $typeDecl . $charset . $default . $notnull . $unique . $check . $collation;

with:
$unsigned = (isset($field['unsigned']) && $field['unsigned']) ? ' ' . $this->getUnsignedFieldDeclarationSQL() : '';
$columnDef = $typeDecl . $unsigned . $charset . $default . $notnull . $unique . $check . $collation;

And implemented getUnsignedFieldDeclarationSQL to return 'UNSIGNED'

After this UNSIGNED field types were generating correct ALTER TABLE statements.

It seems like this kind of approach could safely be integrated into Doctrine DBAL without breaking existing functionality, and making it more usable outside of ORM.

Comment by Stefano Kowalke [ 22/Mar/14 ]

Hi Benjamin,

this is an old issue and I like to try your approach to use the events. Unfortunately I can not find any event code inside MySqlSchemaManager.php but in AbstractSchemaManager.php but I have no idea how to use it. The documentation at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/events.html describes only PostConnect events but. Can you give me some more hints here? I have the same issue like the OP.





[DBAL-844] [GH-549] Fix truncate on MySQL >= 5.5 Created: 22/Mar/14  Updated: 22/Mar/14

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

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


 Description   

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

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

Message:

When truncating tables on MySQL >= 5.5, an error is thrown:

```mysql
SQLSTATE[42000]: Syntax error or access violation:
1701 Cannot truncate a table referenced in a foreign key constraint ...
```

It turns out that with MySQL 5.5.7, `TRUNCATE` behaviour has changed. From the [MySQL docs](http://dev.mysql.com/doc/refman/5.5/en/truncate-table.html):

> TRUNCATE TABLE fails for an InnoDB table if there are any FOREIGN KEY constraints from other tables that reference the table. Foreign key constraints between columns of the same table are permitted.

With this PR foreign key checks are disabled just before and re-enabled just after truncate.

As I encountered this issue using doctrine/data-fixtures, I originally submitted a fix there: https://github.com/doctrine/data-fixtures/pull/127. However, as @deeky666 pointed out, the DBAL is a better place for the fix.






[DBAL-834] SQLServer modifyLimitQuery does not work with aggregate functions in ORDER BY Created: 10/Mar/14  Updated: 21/Mar/14

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

Type: Bug Priority: Major
Reporter: Francesco Montefoschi Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator
Environment:

SQL Server 2008 SP3



 Description   

Starting with Doctrine 2.4, the `modifyLimitQuery` method does not work anymore with query using ORDER BY MAX(...)
See this example:

$sql = "SELECT MAX(heading_id) aliased, code
	FROM operator_model_operator
	GROUP BY code
	ORDER BY MAX(heading_id) DESC
";
$sql = $this->em->getConnection()->getDatabasePlatform()->modifyLimitQuery(
	$sql, 1, 0
);

Doctrine generates this SQL, which is invalid:

SELECT * FROM (SELECT MAX(heading_id) aliased, code
, ROW_NUMBER() OVER (ORDER BY MAX(heading_id) AS doctrine_rownum FROM operator_model_operator GROUP BY code) DESC
) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1

The ORDER BY in moved into the OVER(), but the `preg_replace` in SQLServerPlatform.php stops to replace at the closing ")".



 Comments   
Comment by Francesco Montefoschi [ 10/Mar/14 ]

It is not possible to write `ORDER BY aliased` because it leads to a syntax error in SQL Server.

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

Francesco Montefoschi There have been some modifications to the modifyLimitQuery() method in SQL Server lately for 2.5 which address some problems with subqueries and aggregate functions. Not sure if that might already solve your issue. Can you please check if the problem also exists in the current master branch of DBAL?
See commit: https://github.com/doctrine/dbal/commit/9f3cb437c0f491599de4e1bd847235965f98ffd4

Comment by Francesco Montefoschi [ 11/Mar/14 ]
  - Removing doctrine/common (v2.4.1)
  - Installing doctrine/common (2.4.x-dev 9a7e20e)
    Cloning 9a7e20e779360f3b8a02c27a89d47d5a6fdce8d1

  - Removing doctrine/dbal (v2.4.2)
  - Installing doctrine/dbal (dev-master c61361d)
    Cloning c61361d8fcf65a977d8610ba78eb542a1d2f44b4

  - Removing doctrine/orm (v2.4.2)
  - Installing doctrine/orm (2.4.x-dev a949e87)
    Cloning a949e87ca88299cde368d2b574740753526b62c9

Same issue.

Comment by Flip [ 14/Mar/14 ]

on this line here https://github.com/doctrine/dbal/blob/9f3cb437c0f491599de4e1bd847235965f98ffd4/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L1164

try the following stuffs:

Puts "DESC" in a second capturing group (closer to the original regex, but not sure why you want to do this)
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?)(.*)/

Includes "DESC" in the first capturing group
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?.*)/

Same as last one, except this one stops capturing when it hits a ")" after "DESC"
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?[^)]*)/
Comment by M.K. [ 21/Mar/14 ]

This not only affects Queries with aggregate functions, but every Query that uses a limit and order by an entity-field alias.

Try this Testcase:

$query = $this->em->createQuery("
	SELECT a.id AS test
	FROM prim\\entity\\Article a
	ORDER BY test ASC
");
$query->setMaxResults(10);
echo "<h3>DQL</h3>";
var_dump($query->getDQL());
echo "<br><h3>SQL</h3>";
var_dump($query->getSQL());
echo "<br><h3>Result</h3>";
var_dump($query->getResult());
Comment by Flip [ 21/Mar/14 ]

The test case is incomplete as we don't have `kare\\entity
Article`. Please try the 3 proposed solutions and show the results from those adjustments.

Comment by M.K. [ 21/Mar/14 ]

This is just a sample Query for illustration. Replace it with whatever Entity you like.





[DBAL-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 21/Mar/14

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

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: querybuilder


 Description   

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

Dbal Querybuilder:

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

Expected Query:

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

Resulted Query:

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

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

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

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

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

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

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

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



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

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

Comment by Jeroen Thora [ 21/Mar/14 ]

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





[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/14  Updated: 21/Mar/14

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

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


 Description   

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

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

Message:

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

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



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

Pullrequest related to DBAL-774





[DBAL-518] [GH-318] Update Type.php Created: 15/May/13  Updated: 19/Mar/14  Resolved: 17/May/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 vincequeiroz:

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

Message:

Camel case methods names.



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

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

Comment by Doctrine Bot [ 19/Mar/14 ]

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





[DBAL-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13  Updated: 19/Mar/14

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: postgresql, schematool
Environment:

Windows & Linux



 Description   

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance.

If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail.

--------------------- UPDATE

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.



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

Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier?

Comment by jos de witte [ 24/Apr/13 ]

Dear Benjamin,

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.

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

jos de witte I think your issue got fixed in commit: https://github.com/doctrine/dbal/commit/8beb732fe9d5cd40a0d677f250d2be325482744f
This patch was first introduced in 2.3. Can you please confirm that this is fixed? Otherwise can you please provide a concrete example so that we can reproduce you issue?

Comment by Arnout Standaert [ 29/Jan/14 ]

I believe we are bumping into the same issue. Our webapp uses Migrations, but for our webapp we are limited to a certain schema within a bigger PostgreSQL database. We only have permissions on our own schema and public.
Now, listSequences in AbstractSchemaManager does filter the asset names correctly with the mentioned fix.

But the problem is with the step before, _getPortableSequencesList (see line 135 of AbstractSchemaManager):

        return $this->filterAssetNames($this->_getPortableSequencesList($sequences));

This function goes out and does a _getPortableSequenceDefinition on every sequence in the unfiltered list. For every sequence, the _getPortableSequenceDefinition in PostgreSqlSchemaManager performs a SELECT:

        $data = $this->_conn->fetchAll('SELECT min_value, increment_by FROM ' . $this->_platform->quoteIdentifier($sequenceName));

Now, our user role in the database doesn't have SELECT permissions on these sequences in other schemas, so the migration fails with a privilege error.

There should be some kind of filtering on the sequence list BEFORE the SELECT statement in the _getPortableSequenceDefinition function are performed, no?

Comment by Arnout Standaert [ 30/Jan/14 ]

I currently have a workaround running locally, which filters the sequences list before creating the PortableSequence's. This is probably hackish and a poor workaround, just posting here as a temporary solution and further illustration of the problem.

Altered line 135 in AbstractSchemaManager:

        return $this->_getPortableSequencesList($this->filterSequenceNames($sequences));

I added function filterSequenceNames() in AbstractSchemaManager for appropriate sequence filtering:

    /**
     * Filters sequence names if they are configured to return only a subset of all
     * the found elements.
     *5
     * @param array $sequenceNames
     *
     * @return array
     */
    protected function filterSequenceNames($sequenceNames)
    {
        $filterExpr = $this->getFilterSchemaAssetsExpression();
        if ( ! $filterExpr) {
            return $sequenceNames;
        }
        
        return array_values ( array_filter($sequences, function ($sequenceName) use ($filterExpr) {
                $sequenceName = $sequenceName["schemaname"].".".$sequenceName["relname"];
                return preg_match($filterExpr, $sequenceName);
            })
        );

    }

After these modifications, doctrine:migrations:migrate operations complete succesfully, even with our limited-permission database account.

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

Arnout Standaert Your fix looks promising and reasonable. Can you create a PR on the DBAL repo for that?

Comment by Viktor Sidochenko [ 15/Mar/14 ]

Why this fix is not in master?

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

Viktor Sidochenko because nobody has fixed it yet Feel free to provide a patch on GitHub.

Comment by Arnout Standaert [ 17/Mar/14 ]

I haven't gotten around to doing the PR on GitHub yet, I'm not yet too familiar with that.
I'll try to find some time for this the coming days.

Comment by Viktor Sidochenko [ 17/Mar/14 ]

Will be good. I`m not professional developer to make patches to upstream. So just voted for this issue.

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

Patch supplied in PR: https://github.com/doctrine/dbal/pull/546
jos de witte, Arnout Standaert, Viktor Sidochenko can you please test if the supplied PR fixes the problem?





[DBAL-840] [GH-546] [DBAL-474] Fix filtering sequence names on PostgreSQL Created: 19/Mar/14  Updated: 19/Mar/14

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

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


 Description   

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

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

Message:

The PostgreSQL schema manager has to filter sequence names before actually creating `Sequence` objects to avoid errors on accessing sequence database objects where the user has not enough privileges for.
The reason for this is that retrieving sequence attributes other than the sequence name requires accessing the particular sequence database object directly which requires the connected user to have enough privileges. This might not always be the case if for example a particular user can only access certain schemas but not others.
This patch might not be the best solution but a good compromise IMO. Changing the `AbstractSchemaManager` to filter sequence names before creating `Sequence` objects might affect other platforms and could also perhaps break BC. Furthermore this issue is completely PostgreSQL specific as it is the only currently supported platform not having a sequence's attributes stored directly in the system catalogs (AFAIK).






[DBAL-835] Old column name not quoted during column rename in MySQL Created: 12/Mar/14  Updated: 19/Mar/14

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

Type: Bug Priority: Major
Reporter: Arttu Manninen Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS with Doctrine 2.3 MySQL 5.5.31



 Description   

This is a broken feature, because escaping only sometimes (behavior at least in 2.3, if it has not been fixed after that) leads to breaking things. It is possible to CREATE a column named `usage` (without any backticks in the code), but things break from that point on. If I try to change the column name to a non-reserved word later, ALTER TABLE syntax will break

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE products CHANGE usage purpose VARCHAR(256) NOT NULL':

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'usage purpose VARCHAR(256) NOT NULL' at line 1

Migrating down then again escapes the column name even if it wasn't escaped in the definition.

I found a ticket from 2012 describing that column names using reserved keywords should be escaped manually, but since migrations will lead into a dead-end with at least using `usage` as a column name, this feature is somewhat broken.



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

Arttu Manninen There have been some fixes around quoting identifiers in DDL lately. It seems there is one missing around $oldColumnName in MySqlPlatform::getAlterTableSQL().
I have moved this issue to DBAL as it is an issue there.

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

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





[DBAL-839] [GH-545] [DBAL-835] Quote old column name in rename column SQL Created: 19/Mar/14  Updated: 19/Mar/14

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

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


 Description   

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

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

Message:

Quotes old column name in `ALTER TABLE` statements if necessary when a column gets renamed.

Note: The `AbstractSQLServerPlatformTestCase::getQuotedAlterTableRenameColumnSQL()` method need adjustments as soon as PR #542 gets merged (the `ALTER TABLE` statements need to be removed).






[DBAL-732] MySQL 5.6 - Cannot change column 'fkProjectId': used in a foreign key constraint Created: 24/Dec/13  Updated: 18/Mar/14

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

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

Issue Links:
Reference
is referenced by DBAL-837 Cannot drop index needed in a foreign... Open

 Description   

I'm using doctrine migrations to change a null field to a not null field. MySQL 5.6 is strict on altering tables with foreign key constraint's.

Generated SQL

ALTER TABLE badges CHANGE fkProjectId fkProjectId INT NOT NULL

Result in the following error

Cannot change column 'fkProjectId': used in a foreign key constraint 'FK_1483A5E9F28AE4EA'

More info:

As of 5.6.7, the server prohibits changes to foreign key columns with the potential to cause loss of referential integrity. A workaround is to use ALTER TABLE ... DROP FOREIGN KEY before changing the column definition and ALTER TABLE ... ADD FOREIGN KEY afterward.

Original issue:



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

Cliff Odijk what versions of DBAL/ORM are affected by the bug?

Comment by Cliff Odijk [ 24/Dec/13 ]

Doctrine 2.3.4 / 2a37b007dda8e21bdbb8fa445be8fa0064199e13.

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

Marco Pivetta I wonder whether we should introduce MySqlPlatform567 to fix this which adds this behaviour. We could also fix this is MySqlPlatform directly but I don't know if this impacts performance for older versions of MySQL that don't require this behaviour.

Comment by Timothée Martin [ 09/Jan/14 ]

I encounter the same issue with doctrine/dbal 2.4.2 (commit fec965d330c958e175c39e61c3f6751955af32d0).

Have you any idea of when this bug will be fixed? Or may be can you guide me on how to fix it and I could make a PR on doctrine/dbal.

Thanks.

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

Cliff Odijk , Timothée Martin I will work on this issue as soon as I have time. Expect a fix for this in the upcoming weeks. Thank you for your patience.

Comment by Cliff Odijk [ 28/Jan/14 ]

The same error occurs with MariaDB version 10.0.7

  • InnoDB version 5.6.10
  • doctrine/orm version v2.4.1
  • doctrine/dbal version v2.4.2
Comment by Steve Müller [ 18/Mar/14 ]

I already started work on this but didn't have time to finish it, yet. I will try to find some time for this this evening.





[DBAL-837] Cannot drop index needed in a foreign key constraint Created: 17/Mar/14  Updated: 17/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB version 10.0.7
InnoDB version 5.6.10
doctrine/orm version v2.4.1
doctrine/dbal version v2.4.2


Issue Links:
Reference
relates to DBAL-732 MySQL 5.6 - Cannot change column 'fkP... Open

 Description   

I'm trying to remove an relation from an entity and i'm getting an error that it could not be executed. After testing it, it's missing the DROP FOREIGN KEY query.

The generated SQL is:

DROP INDEX IDX_DCE815B325C79A8C ON moveMembers;
ALTER TABLE moveMembers DROP fkAccessId;

When I use --force to execute it I get the following error:

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'DROP INDEX IDX_DCE815B325C79A8C ON moveMembers':

SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint

[PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint



 Comments   
Comment by Cliff Odijk [ 17/Mar/14 ]

Maybe related to DBAL-732?





[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-788] ORDER BY with function COUNT() fails Created: 08/Jan/14  Updated: 14/Mar/14

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

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

mssql 2008 R2



 Description   

This:
ORDER BY ad.name ASC, count(filter.value) DESC

Fails with:
Error: Expected end of string, got '('



 Comments   
Comment by M.K. [ 15/Jan/14 ]

I have the same problem using SUM() in ORDER BY. I think the doctrine documentation says, that you have to use an alias in ORDER BY. This works fine with MySQL, but fails in MSSQL, because MSSQL doesn't allow aliases in ORDER BY.
I think using aliases in DQL should be fine, so it's rather a problem in SQLServerPlatform class. Aggregate functions in ORDER BY are pretty basic stuff.

Issue should be moved to DBAL.

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

Is using aggregate functions in ORDER BY even possible in SQL Server? It's not clear from the documentation. However it looks like ORDER BY SQL generation might have to be delegated to the specific platform just like LIMIT/OFFSET clauses. This would be another big mess for SQL Server

Comment by M.K. [ 15/Jan/14 ]

I use MSSQL 2008 R2 as well and it seems MSSQL is fine with using aliases in ORDER BY after all. If i run a DQL-Query like that:

SELECT t.id, SUM(pos.price) AS amount
FROM Project\Entity\Task t
LEFT JOIN Project\Entity\Position pos WITH t.id = pos.tid
GROUP BY t.id
ORDER BY amount ASC

... everything is fine. SQL looks like this:

SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1
FROM task t0_ WITH (NOLOCK)
LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
GROUP BY t0_.id
ORDER BY sclr1 ASC

MSSQL seems to be okay with the alias. But if apply a limit on the DQL-Query, SQL looks like this:

SELECT *
FROM (
	SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1, ROW_NUMBER() OVER (ORDER BY sclr1 ASC) AS doctrine_rownum
	FROM task t0_ WITH (NOLOCK)
	LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
	GROUP BY p0_.id
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 50

Execution fails with Error: "Invalid column name 'sclr1'"

I'm not really familiar with MSSQL which is why i decided to use Doctrine after all. But i hope this helps.

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

M.K. Thanks for the detailed information. The fact that you are using a limit here was missing. SQL Server does not support referring to expressions or column aliases from the select list in OVER() clause.
See here: http://msdn.microsoft.com/en-us/library/ms189461.aspx
Could you please test if it possible to specify the SUM() expression directly in the OVER() clause? Like the following:

SELECT *
FROM (
	SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1, ROW_NUMBER() OVER (ORDER BY SUM(p0_.price) ASC) AS doctrine_rownum
	FROM task t0_ WITH (NOLOCK)
	LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
	GROUP BY p0_.id
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 50

If that works we might be able to rewrite the SQLServerPlatform::modifyLimitQuery() to respect that. Otherwise I really don't know what to do about it.

Comment by M.K. [ 15/Jan/14 ]

Yup, using the SUM() expression in the OVER() clause works just fine.

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

M.K. Thank you for investigating. I would like to move this ticket to DBAL because it is a DBAL issue. But I guess that makes two issues now because if I understand correctly, Flip did not use a limit/offset query modification but did not use an alias in the ORDER BY clause either but instead directly specified a COUNT() expression...

Comment by Flip [ 24/Jan/14 ]

I can confirm it works when using an alias. Issue can be closed.

Comment by M.K. [ 14/Mar/14 ]

This issue refers to the same problem:
http://www.doctrine-project.org/jira/browse/DBAL-834





[DBAL-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support Created: 25/Jan/13  Updated: 08/Mar/14

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

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


 Description   

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

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



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

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

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

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

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

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

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

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

Comment by Marco Pivetta [ 28/Feb/14 ]

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

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

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

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

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

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





[DBAL-833] [GH-542] [DBAL-825] Drop default constraints before altering column type on SQL Server Created: 07/Mar/14  Updated: 07/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: sqlserver, sqlsrv

Issue Links:
Duplicate
duplicates DBAL-825 ALTER COLUMN on mssql is failing if d... In Progress
duplicates DBAL-826 [GH-536] [WIP] unit test for DBAL-825 Resolved

 Description   

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

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

Message:

SQL Server implements column default values as constraints and therefore requires them to be dropped before a column type change.
This PR implements the recreation of default constraints on column type alterations.
Additionally some code in `SQLServerPlatform::getAlterTableSQL()` has been refactored to avoid code duplication and unnecessary SQL generation.
Please note that due to the issue's tests the PostgreSQL platform had to be altered to fulfill the same behaviour. PostgreSQL returned some strange default value like `666:smallint` when reverse engineering a column type change with a default value of `666` from type `smallint` to `integer`. So I think this PR fixes a bug in this platform, too. Additionally I had to change the deprecated default value retrieval SQL in PostgreSQL in order to work flawlessly. See the [documentation](http://www.postgresql.org/docs/9.3/static/catalog-pg-attrdef.html) at the very end.

I would also like to note that this PR is definitely not the end of the line concerning default values and column alterations. Some weird errors were revealed on other platforms while fixing this issue. MySQL for example denies default values on BLOB/TEXT type columns, DB2 just throws non-understandable syntax errors around and Oracle seems to map decimal/numeric types without a defined scale to integer when reverse engineering (not really related to this issue but it came up while testing).

Otherwise the tests pass on all platforms.



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

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





[DBAL-825] ALTER COLUMN on mssql is failing if default constraint is attached Created: 03/Mar/14  Updated: 07/Mar/14

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

Type: Bug Priority: Major
Reporter: Thomas Müller Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MSSQL


Issue Links:
Duplicate
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... In Progress
is duplicated by DBAL-826 [GH-536] [WIP] unit test for DBAL-825 Resolved

 Description   

Here is the unit test - implemented in class SchemaManagerFunctionalTestCase

 
    public function testChangeColumnsTypeWithDefault()
    {
        $table = new \Doctrine\DBAL\Schema\Table('column_change_type_test');
        $table->addColumn('id', 'integer', array('default' => 5));

        $this->_sm->createTable($table);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\IntegerType', $columns['id']->getType());

        $tableDiff = new \Doctrine\DBAL\Schema\TableDiff('column_change_type_test');
        $tableDiff->changedColumns['id'] = new \Doctrine\DBAL\Schema\ColumnDiff(
            'id', new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('smallint'), array('default' => 5)
            ),
            array('type'),
            new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('integer'), array('default' => '5')
            )
        );

        $this->_sm->alterTable($tableDiff);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\SmallIntType', $columns['id']->getType());
        $this->assertSame('', $columns['id']->getDefault());
    }

Causes following result

 
Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_change_type_test ALTER COLUMN id SMALLINT NOT NULL':

SQLSTATE [42000, 5074]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The object 'DF_A74995E2_BF396750' is dependent on column 'id'.
SQLSTATE [42000, 4922]: [Microsoft][SQL Server Native Client 11.0][SQL Server]ALTER TABLE ALTER COLUMN id failed because one or more objects access this column.

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

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

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



 Comments   
Comment by Thomas Müller [ 03/Mar/14 ]

Possible solution: http://www.select-sql.com/mssql/how-to-alter-column-with-default-constraint-in-mssql.html

Comment by Thomas Müller [ 03/Mar/14 ]

Here is the unit test: https://github.com/DeepDiver1975/dbal/commit/53238301f7e124d31232e9b3eab774c32c9e04c4

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

Thomas Müller Thanks for reporting. Which version of SQL Server is affected by this?

Comment by Thomas Müller [ 03/Mar/14 ]

SQL Server 2012 Express Edition





[DBAL-826] [GH-536] [WIP] unit test for DBAL-825 Created: 03/Mar/14  Updated: 07/Mar/14  Resolved: 07/Mar/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
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: sqlserver, sqlsrv

Issue Links:
Duplicate
duplicates DBAL-825 ALTER COLUMN on mssql is failing if d... In Progress
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... In Progress

 Description   

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

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

Message:

Here is the unit test for http://www.doctrine-project.org/jira/browse/DBAL-825

Let's see if I can come up with a solution as well ....



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

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

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

Duplicated by DBAL-825 and addressed in DBAL-833





[DBAL-830] [GH-539] unit test added for altering a column's default where the column name is... Created: 04/Mar/14  Updated: 05/Mar/14

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

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


 Description   

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

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

Message:

... a keyword - fails on mssql:

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

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

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

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

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





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

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

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


 Description   

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

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

Message:

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

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

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

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

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

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

{main}

````






[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-827] [GH-537] Update PDOConnection.php Created: 04/Mar/14  Updated: 04/Mar/14

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

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


 Description   

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

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

Message:

Remove lot of if making beautifull code using call_user_func_array






[DBAL-824] [GH-535] added backtrace to query logging Created: 28/Feb/14  Updated: 28/Feb/14

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

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


 Description   

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

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

Message:

I've added a stacktrace to each logged query to be able to display it later on. This can help to find out why a query has been executed.






[DBAL-517] [GH-317] Conditionaly upgrade utf8 to utf8mb4 for MySQL 5.5.3 Created: 15/May/13  Updated: 24/Feb/14  Resolved: 26/May/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 nicolas-grekas:

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

Message:

See http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html

As utf8mb4 is a superset of utf8, this should be transparent and backward compatible.
For those really requiring the "utf8" meant by MySQL, they can use explicitely the utf8mb3 charset.
But IMHO by default, Doctrine should really use utf8mb4, which is what everybody expect from a charset named "utf8".



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

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

Comment by Doctrine Bot [ 24/Feb/14 ]

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





[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-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-795] Error: "database schema is not in sync“ after Create/Update MyISAM tables Created: 11/Jan/14  Updated: 23/Feb/14  Resolved: 23/Feb/14

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: Minor
Reporter: Jacek Hensoldt Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

debian 6.0.3, MySQL 5.1.49, PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli)


Issue Links:
Reference
relates to DBAL-743 [GH-476] Fix foreign key propagation ... Resolved

 Description   

After create or update MyIsam tables: (doctrine orm:schema-tool:create doctrine orm:schema-tool:update --force)

When i check the schema with doctrine orm:validate-schema i get the error message:

doctrine orm:validate-schema
[Database] FAIL - The database schema is not in sync with the current mapping file.

The reason for this is, that Doctrine tries to add a foreign key contraint to myisam-table:

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

...
ALTER TABLE addresses ADD CONSTRAINT FK_6FCA7516A76ED395 FOREIGN KEY (user_id) REFERENCES users (id);


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

Jacek Hensoldt This issue should have been fixed in DBAL in commit: https://github.com/doctrine/dbal/commit/f99f6edde118dda70fe1c2c2f3dee31b6536a335
Can you please check if the problem still exists with the current master branch?

Comment by Jacek Hensoldt [ 12/Jan/14 ]

unfortunately it does not work

I have two tables with these definitions:

/**
 * @Entity @Table(name="addresses", options={"engine"="MyISAM"})
 **/

/**
 * @Entity @Table(name="users", options={"engine"="MyISAM"})
 **/

But aufter create I still get the same error message.

I inserted at line 661 this code:

//lib/Doctrine/DBAL/Platforms/MySqlPlatform.php

$hasOption = $diff->fromTable->hasOption('engine') ? 'YES' : 'NO';
echo "Engine hasOption?:".$hasOption;
echo "Engine: ".$engine;

Output:

Engine hasOption?:NO
Engine: INNODB

The hasOption()-check is working correctly, the problem is, that the engine-option is not set

$diff->fromTable->getOption('engine')

would throw an exception

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

Jacek Hensoldt Confirmed your issue. The problem is that custom table options like the table engine on MySQL don't get reverse engineered by Doctrine currently. Therefore the comparator recognizes differences between the online and offline table which in reality are not there.

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

Okay it's not a comparator issue as it currently does not compare table options at all. The comparator will detect foreign key changes because the online table does not have any foreign keys but your mapping propagates foreign keys through the relation. This cannot be detected in the comparator but has to be evaluated in the platform (which is already fixed). Then I guess the only issue is that the table does not get reverse engineered with the table options set.

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

This is tricky. We need to introspect the table options with the schema manager. Currently reverse engineering the online schema always results in table objects being created without table options. Therefore the comparator will always detect changes. We need to introduce something like AbstractSchemaManager::listTableOptions() and AbstractPlatform::getListTableOptionsSQL(). The latter could potentially be "empty" as currently only MySQL uses table options. Don't know what to do with those platforms. Throw "unsupported" exception? Return empty SQL? Both introduce problems in the schema manager. Throwing exception needs exception handling in the schema manager or another supports*() method in the AbstractPlatform to check against. Returning empty SQL is rather sloppy implementation and also needs handling in the schema manager.

Comment by Marco Pivetta [ 23/Feb/14 ]

After discussion with Steve Müller, I decided that this won't be fixed.

Numerous reasons behind this:

  • MyISAM is not really something we support, since the MySQL platform is built around InnoDB assumptions
  • This goes into specifics of your persistence layer, and it is not really required for the schema tools to support it
  • This will increase the workload for supporting exotic storage layers that we can't really maintain (it's like pandora's box)




[DBAL-807] Index renaming in postgresql does not work when index relates to table inside namespace Created: 08/Feb/14  Updated: 22/Feb/14

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

Type: Bug Priority: Major
Reporter: Artur Eshenbrener Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Open
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Open

 Description   
CREATE SCHEMA test;
CREATE TABLE test.table_name (id INT);
CREATE INDEX idx_1 ON test.table_name (id);

If index would be renamed, generated sql is:

ALTER INDEX idx_1 RENAME TO new_index_name;

But valid sql code should be:

ALTER INDEX test.idx_1 RENAME TO new_index_name;


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

Artur Eshenbrener Can you please provide more details about your use case so that we can reproduce it better. How do you get the wrong SQL?

Comment by Artur Eshenbrener [ 22/Feb/14 ]

I've pushed failing test, reproduces this problem.
https://github.com/doctrine/dbal/pull/532

Comment by Doctrine Bot [ 22/Feb/14 ]

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

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

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





[DBAL-821] [GH-532] DBAL-807 [DBAL-807] - Added failing test reproduces a problem. Created: 22/Feb/14  Updated: 22/Feb/14

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

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

Issue Links:
Reference
relates to DBAL-807 Index renaming in postgresql does not... In Progress
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Open

 Description   

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

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

Message:

Added failing test reproduces problem, decribed in ticket http://www.doctrine-project.org/jira/browse/DBAL-807



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

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





[DBAL-822] [GH-533] [DBAL-807] Respect schema when renaming indexes Created: 22/Feb/14  Updated: 22/Feb/14

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

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

Issue Links:
Reference
relates to DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Open
relates to DBAL-807 Index renaming in postgresql does not... In Progress

 Description   

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

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

Message:

Statements for renaming indexes have to include the schema name if applicable.



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

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





[DBAL-819] Schema-tools does not work on multiple Oracle's schemas Created: 21/Feb/14  Updated: 22/Feb/14

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

Type: Bug Priority: Major
Reporter: Antoine Descamps Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, orm, schematool
Environment:

DB: Oracle 11g



 Description   

The schema-tools, used via the CLI, is not able to detect schema's changes when working on multiple schemas.

For instance, the ORM is configured with a "global" Oracle's user, having permissions on every schemas. To specify which entities belong to which schema, I've prefixed the table name with the corresponding schema.

When trying to do the following command:

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

Doctrine returns me the following message:

Nothing to update - your database is already in sync with the current entity metadata.

If, instead of using the "global" user in the Doctrine's configuration, I set the user of the specific schema I'm trying to generate a table on based from an entity, it works.



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

Moved this to DBAL for now. It seems to be related to schema prefixed table names not being evaluated in the platforms when generating the SQL for reverse engineering the database schema.

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

Antoine Descamps Okay after having investigated on this in detail and thinking about the possibilities we have to find a solution for this, I came to the following conclusion:
ORM's schema tool and DBAL's schema introspection are designed to be bound to what Doctrine defines as "database" for each platform. This is the scope of the whole operation. In case of Oracle it is the "user". You cannot break out of this scope in any way as the current DBAL implementation is not designed for a "complete" schema introspection and therefore does not allow it at some points. Fully understanding your concern I am afraid we cannot find a reasonable solution for your use case at this point in development (2.x). Furthermore there is a good reason for limiting the schema introspection to a certain layer. If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database. This behaviour would even cause a lot more annoyance to users as it is the default use case that users are only interested in one database per entity manager.
Also this problem is completely independant from your mapping definitions. So it doesn't matter whether you prefix your table names or not. When running the "update" operation on the schema tool, it is the online schema introspection part that is preventing the schema tool from behaving as you would wish.
Changing the schema introspection behaviour in DBAL would completely break BC and is at some places in the code not even possible without changing the API.
I am sorry that I have to disappoint you with this conclusion but we I am afraid we cannot do anything about your issue until we start developing 3.x. We might reevaluate your use case their and see what we can do.





[DBAL-409] [GH-245] Added support for column collation Created: 08/Jan/13  Updated: 21/Feb/14  Resolved: 21/Feb/14

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

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


 Description   

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

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

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/5b8f4f0382c20feab9a03e453e22666334f36c9d





[DBAL-810] [GH-526] Add close() method in MasterSlaveConnection.php Created: 11/Feb/14  Updated: 21/Feb/14  Resolved: 21/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: Minor
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 gohiei:

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/594e326bd58d1d7af578f0dc3143655b9d119d45





[DBAL-820] [GH-531] Fix typo and formatting in security docs Created: 21/Feb/14  Updated: 21/Feb/14  Resolved: 21/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: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: documentation


 Description   

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

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

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/3c3a4b14bd9c98c2e27dc98613676442717891a1





[DBAL-818] Fetching identity value from an insert fails with merge replication enabled Created: 20/Feb/14  Updated: 20/Feb/14

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

Type: Bug Priority: Major
Reporter: Michael Anthon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The way that the PDOSqlsrv driver fetches the identity value for a freshly inserted record will fail if there are triggers on a table that do a secondary insert on a table that also has an identity column.

This is the case when you set up merge replication in SQL Server. The replication creates a series of triggers on the tables to catch any of the changes made for the purposes of replication and inserts those changes elsewhere.

We have switched to using the native SQLSrv drivers instead to work around this since that uses "SELECT SCOPE_IDENTITY() AS LastInsertId" to fetch the value during the insert command.



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

I'm not quite sure whether we can fix this is in a reasonable way. See PDO's lastInsertId method in itself is documented to be very inconsistent and behaves differently throughout different drivers and even database versions.

This method may not return a meaningful or consistent result across different PDO drivers, because the underlying database may not even support the notion of auto-increment fields or sequences.

Because of this we do not have tests in our testsuite yet that cover the last insert id topic that work as expected on all drivers.
IIRC the fact that DBAL's implementation for the native sqlsrv driver uses "SELECT SCOPE_IDENTITY() AS LastInsertId" is a workaround to support this feature at all and come around the driver limitation IIRC. This as such is a dirty workaround and should IMO not be relied on for scenarios such as you describe.
I'm not quite sure what the expected behaviour of PDO drivers in general would be concerning triggers on PK columns that do other inserts regarding last insert IDs. IMO this is not a Doctrine bug but rather an unsupported use case or even a driver bug/limitation? Not sure on this.
The only thing we could actually do is implement the same workaround we have in the native sqlsrv driver for the PDO driver. But I would rather not do this for such an edge case scenarion.
But that's just my opinion

Comment by Michael Anthon [ 20/Feb/14 ]

Yes, I agree that any workaround will be a bit of a dirty hack.

The main problem is the PDO driver using @@identity to get the last inserted id, which is pretty much the wrong way to do it in all but the simplest of cases... SCOPE_IDENTITY is there for a reason but won't work when called subsequently since it's run inside an sp_prepexec and will be out of scope anyway (it has to be tacked onto the end of the insert statement as it is in the sqlsrv driver)

There's another piece of code in the SQLSrvConnection that uses this method...

 $sql = "SELECT IDENT_CURRENT(".$this->quote($name).") AS LastInsertId";

That could potentially be used as well and would probably give a more accurate answer but is also subject to race conditions on busy systems.





[DBAL-234] Index names are not synchronized by Comparator Created: 08/Mar/12  Updated: 19/Feb/14  Resolved: 29/Dec/13

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

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

MySQL


Issue Links:
Duplicate
is duplicated by DBAL-566 Schema Comparator does not identify r... Resolved
Reference
is referenced by DDC-2989 ORM should allow custom index names f... Open

 Description   

Index and foreign key name change is not synced by Comparator.

This is important since in some complex queries one might use FORCE INDEX (some_index_name), and they will fail if an index name is incorrect.



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

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

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-566] Schema Comparator does not identify renamed indexes Created: 23/Jul/13  Updated: 19/Feb/14  Resolved: 29/Dec/13

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

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

Issue Links:
Duplicate
duplicates DBAL-234 Index names are not synchronized by C... Resolved
Reference
is referenced by DDC-2989 ORM should allow custom index names f... Open

 Description   

The schema comparator does not identify renaming of used declared indexes.

This is partly due to the renamed index always fulfilling itself
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Comparator.php#L440

it looks like the logic for columns should be repeated, where renames are detected.



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

May I ask what advantages you get when the comparator detects renamed indexes? An ALTER TABLE statement would still have to drop and recreate the index, doesn't it?

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

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

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

Comment by Ben Davies [ 02/Jan/14 ]

Awesome Steve!





[DBAL-816] [GH-529] fix for postres listTableNames Created: 18/Feb/14  Updated: 18/Feb/14

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

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


 Description   

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

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

Message:

fix for listTableNames to return unescaped table names






[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-553] PostgreSQL JSON Type Created: 03/Jul/13  Updated: 18/Feb/14  Resolved: 29/Dec/13

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

Type: New Feature Priority: Minor
Reporter: Martin Prebio Assignee: Steve Müller
Resolution: Fixed Votes: 2
Labels: JSON, PostgreSQL

Issue Links:
Duplicate
is duplicated by DBAL-815 Returning a wrong field type for Post... Resolved

 Description   

Since version 9.2 PostgreSQL has a new data type for JSON fields: http://www.postgresql.org/docs/9.2/static/datatype-json.html

The current json_array datatype works on this field if it was not created by Doctrine but manually but it would be nice to support the field type also for schema generation.

I can offer a Pull Request for this change but I have not found a method for determining the database version.



 Comments   
Comment by Daniel Londero [ 18/Jul/13 ]

It would be great to have JSON datatype! In the mean time the solution is creating a "Custom Mapping Type", right?

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

Benjamin Eberlei We could adopt the GuidType implementation here with checking on the platform if it supports native json type and use that instead. What do you think?

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

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

Comment by Doctrine Bot [ 29/Dec/13 ]

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

Comment by Benedikt Allendorf [ 16/Feb/14 ]

It seems that this feature is already in the documentation (http://doctrine-dbal.readthedocs.org/en/latest/reference/types.html#mapping-matrix) although it is only included in the next version of DBAL (2.5).





[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-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-812] SchemaTool ignores multi-columns (composite) indexes when creating a foreign key Created: 13/Feb/14  Updated: 15/Feb/14

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Peter Huynh Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

MySQL



 Description   

When using the schema tool to generate the differences between the db and the entities, I notice the following:

ALTER TABLE sales ADD CONSTRAINT FK_36D222EF603EE73 FOREIGN KEY (vid) REFERENCES vendor (id);
CREATE INDEX IDX_36D222EF603EE73 ON sales (vid);

Normally, it doesn't bother me, however I have had an existing composite index consists of (vid, submit). This leads to the redundant index IDX_36D222EF603EE73 and therefore forcing unnecessary overheads.

It would be nice to have a mean to disable this from happening.

The code in question can be found at https://github.com/doctrine/dbal/blob/594e326bd58d1d7af578f0dc3143655b9d119d45/lib/Doctrine/DBAL/Schema/Table.php#L543.

A helpful member from #doctrine IRC also pointed out that it does not check the unique constraints also.

Regards,



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

Just a hint on this: looks like the current logic just checks hashed indexes, ignoring the "uniq" prefixed indexes to avoid duplicates.

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

Peter Huynh I get the point here. However after having a quick look into this it seems this behaviour exists for a good reason. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Index.php#L191-L195
The question is how could this reasonable extended to fulfil the needs you explained. I am not entirely sure about this and this peace of code is rather sensitive and critical. I don't want to rush any assumptions here.

Comment by Peter Huynh [ 15/Feb/14 ]

Hi Steve,

I fully understand your reservation.

Thanks for looking into things.

Peter





[DBAL-764] Provide a reference of the portable Column types and options Created: 04/Jan/14  Updated: 15/Feb/14  Resolved: 15/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: Documentation Priority: Minor
Reporter: Frederic G. MARAND Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: Cli, documentation

Attachments: File SchemaReferenceCommand.php    

 Description   

One difficulty I had with the existing documentation and tools for DBAL was the lack of a reference for what the valid values were (e.g. "notnull" instead of "not null").

See http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html for example: some values are given, but there is no reference list, and anything put just in documentation would incur the risk of not remaining updated.

So I tried to guess-generate the information from the code, like this: https://gist.github.com/FGM/8261606 (also attached).

Unless an equivalent already exists somewhere, I think it could be useful to have something like this in upcoming releases.



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

Documentation supplied in PR: https://github.com/doctrine/dbal/pull/502
Please give a shout if something is missing, wrong, arguable or what...

Comment by Frederic G. MARAND [ 09/Jan/14 ]

Glad to see so much information in your PR. Did you create it from scratch or was it available elsewhere ?

Also, since the project seems to have some difficulty keeping up with "guide"-type documentation vs code evolutions, wouldn't it be feasible to have most of this information be generated from code (or phpdoc), to have it be automatically maintained when code changes ?

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

Frederic G. MARAND I created it from scratch as you requested in this ticket. We are aware the DBAL documentation isn't in the best shape, but we are working on it step by step. Please bare with us if it takes some time to catch up all the missing things.
An API documentation is always autogenerated and published automatically on the Doctrine website: http://www.doctrine-project.org/api/dbal/2.4/index.html

Comment by Frederic G. MARAND [ 09/Jan/14 ]

OK, i was afraid it was somewhere and I had missed it. Beyond that, don't you think it would be a good idea to have such lists of information be maintained as phpdoc rather than in the doc sources, and exported instead of being types. This would allow such commands as the one I had imagined (obviously better done).

Comment by Doctrine Bot [ 08/Feb/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/6adc9ee1cb51e4ffef9811cf1d63de152824dd0d





[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-811] [GH-527] Birko boolean conversion Created: 12/Feb/14  Updated: 12/Feb/14

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

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


 Description   

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

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

Message:

Added platform specific conversion form database Boolean type to PHP bool type






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

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

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


 Description   

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

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

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

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



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

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

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

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

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

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

and

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

Partial support for SQL Server has already been merged in:

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

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

Comment by John Flatness [ 26/Nov/13 ]

I believe that does answer my question.

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

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

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

Comment by John Flatness [ 26/Nov/13 ]

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

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

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

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

Comment by Doctrine Bot [ 11/Feb/14 ]

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





[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-808] [GH-525] Added flags support for mysqli::real_connect in Mysqli driver. Created: 08/Feb/14  Updated: 08/Feb/14

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

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


 Description   

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

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

Message:

This is necessary if you want to set connection options like compression or SSL encryption.

Recently I wanted to use DBAL with Mysqli driver and I noticed that there is no possibility to enable connection compression, which is done in mysqli by setting flags to mysqli::real_connect. DBAL Mysqli driver lacks support for setting any flag, so I decided to propose my change to add such possibility.






[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-804] [GH-523] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 08/Feb/14

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

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

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
is duplicated by DBAL-803 SQLSTATE[HY093]: Invalid parameter nu... Resolved

 Description   

I am using this code from documentation

QueryBuilder Positional with ?
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

... and I also tried

QueryBuilder Positional with ?1
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

but I got this error:

Error in test case deletePositionalParameter
File: vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php
Line: 91
An exception occurred while executing 'DELETE FROM test_t3lib_dbtest WHERE fieldblub = ?' with params [1391699318]:

SQLSTATE[HY093]: Invalid parameter number: parameter was not defined

When I provide a type to setParamter like

QueryBuilder Positional with ?1 and type
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME'], \PDO::PARAM_INT);
$query->execute();

or when I changed it to a named query it works

QueryBuilder Positional with named query
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = :test')
$query->setParameter(':test', (int)$GLOBALS['EXEC_TIME']);
$query->execute();

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

Message:

Creating Unit Tests to proof the behavior. Its my first PR and I
don't know if I created the Unit Test in the right place. It was the
location where the test actually writing to database which is needed
provoke the error.

DBAL-803 #Provides a test for this issue



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

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

Comment by Benjamin Eberlei [ 08/Feb/14 ]

Fixed in the docs.





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