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

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2.3, 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-329] [GH-190] Fix DDC-1978 Created: 26/Aug/12  Updated: 29/Aug/12  Resolved: 29/Aug/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2.3, 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-323] [GH-185] Add schema changes for length for postgres Created: 17/Aug/12  Updated: 06/Oct/12  Resolved: 06/Oct/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2.3, 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-299] Multiple different interspersed named parameters Created: 06/Jul/12  Updated: 07/Jul/12  Resolved: 07/Jul/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2.3
Fix Version/s: 2.2.3
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-285] Schema generation fails when primary key is quoted Created: 23/May/12  Updated: 04/Jul/12  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: 2.2.3
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-276] MySQL schema manager should not make assumptions about non-DBAL types Created: 16/May/12  Updated: 27/May/12  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, 2.2.3
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-269] [GH-141] Fixed conditional expression Created: 05/May/12  Updated: 27/May/12  Resolved: 27/May/12

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

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

Message:






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

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.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 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-261] MasterSlaveConnection fails to load ConnectionEventArgs Created: 24/Apr/12  Updated: 05/May/12  Resolved: 05/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2.1, 2.2.2
Fix Version/s: 2.2.3
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-257] OCI8Statement::fetchColumn() returns null instead of false Created: 16/Apr/12  Updated: 05/May/12  Resolved: 05/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2
Fix Version/s: 2.2.3
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-255] On SQL SERVER Trying to drop a column throws error because of auto generated Constraints Created: 13/Apr/12  Updated: 05/May/12  Resolved: 05/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.2.2
Fix Version/s: 2.2.3
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-254] SQL Server rename table should use sp_RENAME Created: 11/Apr/12  Updated: 08/Jul/12  Resolved: 08/Jul/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.2.1
Fix Version/s: 2.2.3
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-244] Shema Tool is not working after DBAL-177 for postgresql (mysql working like before) Created: 25/Mar/12  Updated: 05/May/12  Resolved: 05/May/12

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

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-214] Unable to use PDO::FETCH_CLASS with a call to fetch() Created: 30/Jan/12  Updated: 05/May/12  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.0.9, 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
Fix Version/s: 2.2.3, 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-202] Preparing Statements outside Transaction Created: 15/Jan/12  Updated: 05/May/12  Resolved: 05/May/12

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





Generated at Thu Apr 17 01:14:51 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.