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





Generated at Sat Apr 19 19:41:05 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.