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

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

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


 Description   

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

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

Message:

Hey guys,

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

Adrien



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

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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





[DBAL-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-346] Generated schema fails on MySQL (BLOB/TEXT cant have DEFAULT value) Created: 19/Sep/12  Updated: 20/Sep/12  Resolved: 20/Sep/12

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

Type: Bug Priority: Major
Reporter: Sascha Ahmann Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: Cli, schematool
Environment:

Symfony 2.1.x (dev/master), Doctrine 2.2.3, MySQL 5.5.x



 Description   

In my symfony 2.1 project i was including JMSPaymentCoreBundle and did the vanilla installation.

After that i ran

php app/console doctrine:schema:update --dump-sql
php app/console doctrine:schema:update --force

A lot of schema updates were done. I ran it again, and two schema updates were still showing up.
Running the command again, and they still show up.

I then tried to run the two schema updates against my database and MySQL complains with the following error:

Error: 1101 - BLOB/TEXT column 'extended_data' can't have a default value

According to the Documentation BLOB/TEXT indeed cannot have default values. I am not sure why Doctrine thinks it has to set this default value.

The statements look like this:

sascha@debian:/var/www/myproject/Symfony$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE payment_instructions CHANGE extended_data extended_data LONGTEXT NOT NULL COMMENT '(DC2Type:extended_payment_data)';
ALTER TABLE financial_transactions CHANGE extended_data extended_data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:extended_payment_data)'

I already reported this problem in the JMSPaymentCoreBundle Issue Queue where i then was referred to over here.

Also, i am not sure if Doctrine DBAL is the best match for this issue, so if it is wrong please move it to the right project issue queue.

Thank you very much and best of Regards!
Sascha






[DBAL-342] [GH-198] Change default MySQL table collation to utf8_unicode_ci Created: 14/Sep/12  Updated: 03/Dec/13  Resolved: 17/Sep/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 VladanStef:

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

Message:

I think default table collation should be changed to `utf8_unicode_ci`, as it handles properly a much wider array of characters (Cyrillic, for example) at a generally negligible cost of performance.

`utf8_general_ci` simply does not work properly with too many languages and should be avoided as a default.



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

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

Comment by Benjamin Eberlei [ 17/Sep/12 ]

Merged into 2.3

Comment by William Knak [ 12/Nov/12 ]

What about leaving default collate empty? So it will inherit database default collation / charset. I've just created a ticket suggesting that #DDC-2139 . Because we're experiencing trouble using Symfony2 commands to create database, than create schema/tables/fields, always use "utf8_unicode_ci" instead of our database default collate.

Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DBAL-341] [GH-197] Bugfix for DDC-2013 Created: 13/Sep/12  Updated: 17/Sep/12  Resolved: 17/Sep/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 naitsirch:

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

Message:

Bugfix DDC-2013 - Default Session Value ".," for "NLS_NUMERIC_CHARACTERS". This is needed because Oracle uses other characters for decimal separation depending on the servers locale.

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



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

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





[DBAL-345] When inserting decimals into Oracle, getting ORA-01722: invalid number Created: 04/Sep/12  Updated: 17/Sep/12  Resolved: 17/Sep/12

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

Type: Bug Priority: Major
Reporter: Christian S. Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: decimal, number, oracle, separator
Environment:

Windows 7 (German), Oracle XE 11.2.0, Doctrine 2.2.2, Symfony 2.0.15



 Description   

When I insert decimals into database I get the following error message:

ORA-01722: invalid number

Oracle wants decimals (e.g. NUMBER(5,2)) separated by comma instead of a dot. I think the reason is that I use the german version of Windows. I tried to modify the following method of \Doctrine\DBAL\Driver\OCI8\OCI8Statement::bindValue() just for testing of course:

    public function bindValue($param, $value, $type = null)
    {
        if (is_float($value)) {
            $value = str_replace('.', ',', (string) $value); // <--
        }
        return $this->bindParam($param, $value, $type);
    }

With this modification I do not get the error anymore.
It would be great if a solution could be found. The strange thing is, if I query "SELECT * from nls_database_parameters where PARAMETER='NLS_NUMERIC_CHARACTERS'" I get ".," which means that a dot is already used as decimal separator. Maybe Oracle preferes the Locale of the OS?!
Maybe you could provide a setting which defines what separator should be used for decimals.

I found some Links that might be interesting regarding this issue:



 Comments   
Comment by Christian S. [ 04/Sep/12 ]

I found out that the database session has the parameter 'NLS_NUMERIC_CHARACTERS', too.
When I query it by the following SQL query:

SELECT parameter,value FROM v$nls_parameters WHERE parameter = 'NLS_NUMERIC_CHARACTERS'

I get this result:

,.

With doctrine I can get the parameter with this (in Symfony2):

$conn = $this->getDoctrine()->getEntityManager()->getConnection(); /* @var $conn \Doctrine\DBAL\Connection */
$query = $conn->executeQuery("SELECT parameter,value FROM v\$nls_parameters WHERE parameter = 'NLS_NUMERIC_CHARACTERS'"); /* @var $query \Doctrine\DBAL\Driver\OCI8\OCI8Statement */
$result = $query->fetchAll(\PDO::FETCH_ASSOC);
print_r($result);

In this case I get this output:

Array
(
[0] => Array
(
[PARAMETER] => NLS_NUMERIC_CHARACTERS
[VALUE] => ,.
)

)

And with

ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '. '

I can change the parameter.

When I execute the above query before I do my insert with decimal values, everything works as expected
But it would be nicer if I could do that with a configuration.

Comment by Benjamin Eberlei [ 05/Sep/12 ]

There is an Oci8SessionInitListener inside Doctrine DBAL. It does not yet contain the numeric character change. Can you open a pull request on Github DBAL to add this?

Comment by Christian S. [ 13/Sep/12 ]

Hi Benjamin.
I have opened a pull request on Githup: https://github.com/doctrine/dbal/pull/197
I hope everything is correct, because this is my first Pull-Request

Comment by Benjamin Eberlei [ 17/Sep/12 ]

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





[DBAL-338] Typo in AbstractPlatform for GUID type declaration Created: 04/Sep/12  Updated: 05/Sep/12  Resolved: 05/Sep/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: Marijn Huizendveld Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

has been fixed in 3f5fda98299acdcda9965e8e797cbcd0490f0dcc, however it's not merged into 2.3.






[DBAL-339] setFetchMode arguments exception Created: 03/Sep/12  Updated: 05/Sep/12  Resolved: 05/Sep/12

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

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

PDO_MySql



 Description   

i have this error in version 2.3.0-RC1

in DBAL/STatement.php on aound line 191 you will find:

public function setFetchMode($fetchMode, $arg2 = null, $arg3 = null)

{ return $this->stmt->setFetchMode($fetchMode, $arg2, $arg3); }

the problem is that php throws me a Exception:
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: fetch mode doesn't allow any extra arguments'

the reason for the exception is that setFetchMode doesnt support null as second/third argument.

somebody also described it in the php issue tracker:
https://bugs.php.net/bug.php?id=54545



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

Fixed





[DBAL-335] Is MasterSlaveConnection implemented correctly - seems to overwrite master connection on transaction methods? Created: 31/Aug/12  Updated: 22/Sep/12  Resolved: 17/Sep/12

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

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


 Description   

Forgive me to doubt, but I think there may be a bug in MasterSlaveConnection.

It's easier to understand what I'm saying by debugging and tracing the flow, but I'll illustrate it with gists.

First, here is a simple service method to create a user. It opens up a transaction, persists the user, commits and returns. On error, if there is an active transaction, rollback. Here is the gist:

https://gist.github.com/3547674

The "$conn->beginTransaction();" line is where we trace through (the remainder of the service method is now irrelevant). Looking into MasterSlaveConnection.php, we see the method tries to connect to the master connection (call this point ###):

https://gist.github.com/3547720

Now looking in the next gist, we see what happens when "$this->connect('master');" is called. At this point it's not that interesting, the internal "$this->_conn" property is set to "master".

https://gist.github.com/3547750

Now here lies the bug I believe. "parent::beginTransaction();" is called. When looking into this method, we see that another call is made to connect but this time without "master" as the argument (i.e. connect to slave). This call to connect is made before incrementing the transaction nesting level.

https://gist.github.com/3547808

Now, I won't do another gist for "MasterSlaveConnection::connect", but if you refer to the file at line 13 https://gist.github.com/3547750#file_master_slave_connection.php, you will see that it checks the transaction nesting level and if it is there, forces master. However, we don't increment the level until after the method returns, so the slave is used. Ultimately, this results in the internal "$this->_conn" property set to the "slave" connection which violates our original action at ### above where we said we want to connect to "master".

Am I missing something here? Here is a gist the is a basic attempt at fixing this one method. It simply copies the code from the parent method except does not connect twice. I believe the same would have to occur for all the other methods unless it can be fixed once at the "MasterSlaveConnection::connect" level.

https://gist.github.com/3547880

I've just fleshed out "beginTransaction", "commit" and "rollBack" in "MasterSlaveConnection" by basically copying and pasting the code from the parent class and for my failing use case, this fixes the issue. However, it did require updating "Connection" slightly so that I had access to some private variables.



 Comments   
Comment by Lars Strojny [ 31/Aug/12 ]

This looks indeed like a bug. From a first glimpse the fix would be to use master, if master is already connected.

Comment by Benjamin Eberlei [ 05/Sep/12 ]

This only happens when "keepSlave" = true, because then the master is not written into the slave property aswell:

   } else {
     $this->connections['slave'] = $this->_conn = $this->connectTo($connectionName);
   } 

Are you using keepSlave = true?

Comment by Jonathan Ingram [ 05/Sep/12 ]

Yes I am. Does that render this moot or still a bug?

Comment by Benjamin Eberlei [ 06/Sep/12 ]

Its still a bug, but it helps to know why this happens.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

Fixed in master and 2.3, can you test it?

Comment by Jonathan Ingram [ 19/Sep/12 ]

Thanks for doing this. I will test it shortly.

Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

not sure if you managed to test this but now test on mysql database fails with results below.
Probably some typo.

There was 1 error:

1) Doctrine\Tests\DBAL\Functional\MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster
Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

With queries:
2. SQL: 'CREATE TABLE master_slave_table (test_int INT NOT NULL, PRIMARY KEY(test_int)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

Trace:
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DbalFunctionalTestCase.php:73
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/DBALException.php:47
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92





[DBAL-334] [GH-194] Small test fixes for PostgreSQL Created: 29/Aug/12  Updated: 05/Sep/12  Resolved: 05/Sep/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 posulliv:

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

Message:

When running the test suite against a clean PostgreSQL install on a 64-bit system I hit 2 issues:

  • dropDatabase calls fail unless a database is manually created
  • TypeConversionTest::testIdempotentDataConversion fails expecting bigint type to be converted to a string. PostgreSQL seems to detect 32 vs 64 bit systems and casts correctly for bigint types.

This small patch allows the test suite to run successfully for me against clean MySQL & PostgreSQL installs.



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

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

Comment by Benjamin Eberlei [ 05/Sep/12 ]

Fixed





[DBAL-322] Change Detection fails when 'unsigned' is used in MySQL Schema Created: 14/Aug/12  Updated: 14/Aug/12  Resolved: 14/Aug/12

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

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


 Comments   
Comment by Marcus Stöhr [ 14/Aug/12 ]

This has been already fixed in https://github.com/doctrine/dbal/commit/e44a6c36a8d9e0aa8d8abb2c91c443ced5a6e39e.





[DBAL-315] [GH-182] Added a missing method in the Constraint interface Created: 06/Aug/12  Updated: 14/Aug/12  Resolved: 14/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: Alexander
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This adds a missing method in the Constraint interface. The method is already defined in AbstractAsset which is extended by both classes implementing the interface. the AbstractPlatform is calling this method on objects after checking they are implementing the interface. So either the method should be part of the interface, or all places using the interface as typehint should be refactored to check for the classes (examples can be found [here](https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L1029) and [there](https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L1254)).

Adding a method in an interface is technically a BC break but this method is not really a public extension point. what do you think @beberlei ?



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

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





[DBAL-314] [GH-180] Fixed some phpdoc Created: 06/Aug/12  Updated: 14/Aug/12  Resolved: 14/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 stof:

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

Message:

This fixes some phpdoc in the AbstractPlatform and in some child classes. I haven't checked all child classes to ensure that all phpdoc is right now, but the abstract one is now accurate (but a bunch of method are missing their phpdoc altogether)



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

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





[DBAL-302] [GH-168] DebugStack should ignore stopQuery when disabled Created: 09/Jul/12  Updated: 10/Jul/12  Resolved: 10/Jul/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 dpb587:

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

Message:

I noticed that DebugStack was adding an empty element when it was disabled. This PR changes it to match startQuery with its behavior.

1) Doctrine\Tests\DBAL\Logging\DebugStackTest::testLoggedQueryDisabled
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array
(
+ [0] => Array
+ (
+ [executionMS] => 1341871660.9651
+ )
+
)

I've submitted the PR to 2.0.x since that's where the bug is first seen and is still listed as stable on doctrine-project.org. Preferably this could also be applied to newer branches as well, or I can also submit separate PRs.



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

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





[DBAL-301] [GH-167] Oracle stored procedures Created: 07/Jul/12  Updated: 29/Jul/12  Resolved: 29/Jul/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 AduroIdea:

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

Message:

driver function
To avoid ORA-03131 error, data length must be passed to oci_bind_by_name function.
This commit fixes it so now pdo_oci can be used with stored procedures and output parameters from sql/plsql.



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

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

Comment by Benjamin Eberlei [ 07/Jul/12 ]

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

Comment by Benjamin Eberlei [ 07/Jul/12 ]

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

Comment by Benjamin Eberlei [ 07/Jul/12 ]

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





[DBAL-298] [GH-166] Fixes a bug caused by unquoted reserved table name being referenced during schema creation Created: 05/Jul/12  Updated: 29/Jul/12  Resolved: 29/Jul/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 klaussilveira:

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

Message:

When creating a schema with tables with reserved names and relationships between them, the schema creation tool failed to write valid SQL in MySQL due to unquoted table names. For example:

CREATE TABLE `Group` (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL DEFAULT NULL, PRIMARY KEY(id)) ENGINE = InnoDB;
CREATE TABLE User (id INT AUTO_INCREMENT NOT NULL, username VARCHAR(255) NOT NULL PRIMARY KEY(id)) ENGINE = InnoDB;
CREATE TABLE UserHasGroup (user_id INT NOT NULL, group_id INT NOT NULL, INDEX IDX_617A865CA76ED395 (user_id), INDEX IDX_617A865CFE54D947 (group_id), PRIMARY KEY(user_id, group_id)) ENGINE = InnoDB;
ALTER TABLE UserHasGroup ADD CONSTRAINT FK_617A865CA76ED395 FOREIGN KEY (user_id) REFERENCES User (id);
ALTER TABLE UserHasGroup ADD CONSTRAINT FK_617A865CFE54D947 FOREIGN KEY (group_id) REFERENCES Group (id);

This fix creates a small function for creating quoted foreign key table names.



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

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

Comment by Benjamin Eberlei [ 29/Jul/12 ]

Merged





[DBAL-295] [GH-164] Getters for AbstractAsset$_quoted and ForeignKeyConstraint$_options Created: 04/Jul/12  Updated: 05/Jul/12  Resolved: 05/Jul/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 tyler-sommer:

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

Message:

Added the necessary getters, re: doctrine/migrations#79



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

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





[DBAL-296] [GH-165] interface compatibility Created: 04/Jul/12  Updated: 05/Jul/12  Resolved: 05/Jul/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 Nazin:

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

Message:



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

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





[DBAL-288] [GH-156] [Platform] Allow a string to be passed as type Created: 27/May/12  Updated: 23/Dec/13  Resolved: 27/May/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 schmittjoh:

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

Message:



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

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

Comment by Doctrine Bot [ 23/Dec/13 ]

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





[DBAL-287] [GH-155] Update license for Composer Created: 26/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.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 jalliot:

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

Message:



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

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





[DBAL-283] [GH-151] Fixed the doctrine/common constraint and added the branch-alias Created: 20/May/12  Updated: 22/May/12  Resolved: 22/May/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 stof:

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

Message:

The change in the requirements requires doctrine/common#144 to be merged and parsed by Packagist, otherwise ``2.3.*`` would not match anything.



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

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





[DBAL-280] [GH-148] No bug. Respect the case used in the interface Created: 17/May/12  Updated: 22/May/12  Resolved: 22/May/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 pap-florin:

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

Message:



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

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





[DBAL-279] [GH-147] 2.2 Add lastInsertId() support for OCI8 Driver Created: 16/May/12  Updated: 22/May/12  Resolved: 22/May/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 franek:

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

Message:

Add lastInsertId() support for Sequence






[DBAL-278] add support for lastInsertId method on OCI8 Driver Created: 16/May/12  Updated: 22/May/12  Resolved: 22/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Franek Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

oci8



 Description   

The method lastInsertId() is not defined for OCI8 Driver in Doctrine\DBAL\Driver\OCI8\OCI8Connection.php :

OCI8Connection.php
public function lastInsertId($name = null)
{
    //TODO: throw exception or support sequences?
}

I propose this method to handle lastInsertId for sequence :

OCI8Connection.php
public function lastInsertId($name = null)
 {
        // For sequence
        if (is_string($name)) {
            // We can check eventually check the presence of the sequence in the table
            // USER_SEQUENCES
            $sql = 'SELECT ' . $name . '.CURRVAL FROM DUAL';
            // will throw an exception if this sequence does not exist
            $stmt = $this->query($sql);
            $result = $stmt->fetch(\PDO::FETCH_ASSOC);
            if ($result !== false && isset($result['CURRVAL'])) {
                return (int) $result['CURRVAL'];
            }
    }
    // OCI8 driver does not provide support of lastInsertId
    return null;
}

Thanks,






[DBAL-282] [GH-150] Added missing regex delimiters in the testsuite Created: 18/May/12  Updated: 22/May/12  Resolved: 22/May/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 stof:

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

Message:

The AbstractSchemaManager expects getting the regex with its
delimiters since 8beb732fe9 but the tests were not updated.



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

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





[DBAL-281] [GH-149] changed some phpdoc's, set correct namespaces and types Created: 18/May/12  Updated: 22/May/12  Resolved: 22/May/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 Engerim:

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

Message:



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

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





[DBAL-272] [GH-144] [MYSQLI] Fixed infinite loop in fetchAll() Created: 08/May/12  Updated: 09/May/12  Resolved: 09/May/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 kimhemsoe:

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

Message:



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

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





[DBAL-270] [GH-142] Dbal 264 Created: 05/May/12  Updated: 22/May/12  Resolved: 22/May/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 rivaros:

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

Message:

added support for Postgres UUID type.






[DBAL-273] Allow MasterSlave Connection to switch back to slave Created: 11/May/12  Updated: 28/Dec/13  Resolved: 28/Dec/13

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

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


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

Fixed in commit: https://github.com/doctrine/dbal/commit/4eaa44c057c228ea7a2fa9cb6cff0b9f94529528





[DBAL-271] [GH-143] added simple_array type Created: 07/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.3
Security Level: All

Type: Improvement 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 schmittjoh:

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

Message:






[DBAL-266] [GH-139] [Mysql Platform] Added mapping for binary and varbinary. Created: 01/May/12  Updated: 04/May/12  Resolved: 04/May/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 kimhemsoe:

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

Message:



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

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





[DBAL-262] [GH-136] Support oci8 in TableGenerator 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.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/136

Message:

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

This test was breaking when running under `oci8` due to Oracle's deference to upper case column names. I realize Oracle has built-in sequences and `TableGenerator` is unnecessary, in theory, but it seemed like the class should work if possible. I see pgsql is in the same boat.

Tested with:

phpunit -c oci8.phpunit.xml.dist tests/Doctrine/Tests/DBAL/Functional/TableGeneratorTest.php

Before:

PHPUnit 3.5.13 by Sebastian Bergmann.

EE

Time: 0 seconds, Memory: 10.25Mb

There were 2 errors:

1) Doctrine\Tests\DBAL\Functional\TableGeneratorTest::testNextVal
Exception: [Doctrine\DBAL\DBALException] Error occured while generating ID with TableGenerator, aborted generation: Undefined index: sequence_value

2) Doctrine\Tests\DBAL\Functional\TableGeneratorTest::testNextValNotAffectedByOuterTransactions
Exception: [Doctrine\DBAL\DBALException] Error occured while generating ID with TableGenerator, aborted generation: Undefined index: sequence_value

After:

PHPUnit 3.5.13 by Sebastian Bergmann.

..

Time: 1 second, Memory: 10.25Mb

OK (2 tests, 5 assertions)



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

Fixed

Comment by Benjamin Eberlei [ 05/May/12 ]

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





[DBAL-259] [GH-134] Removed Paranthesis to allow for more complex Regex Created: 17/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.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 Hounddog:

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

Message:

Needed to remove the Paranthesis to allow for complex Regular Expressions. e.g Exclusion of tables



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

Fixed





[DBAL-250] [GH-128] [DBAL-249] result cache with fetch type PDO::FETCH_COLUMN Created: 05/Apr/12  Updated: 04/May/12  Resolved: 04/May/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 gedrox:

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

Message:

This should enable caching of results retrieved by PDO::FETCH_COLUMN fetch type.
Before this exception "Invalid fetch-style given for caching result" was raised.

Should work now.

(This replaces a previous pull request #126 I failed to make right... sorry)



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

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





[DBAL-251] [GH-130] [mysqli] Added support for fetchAll(PDO::fetch_column) Created: 07/Apr/12  Updated: 16/Apr/12  Resolved: 16/Apr/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 kimhemsoe:

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

Message:



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

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





[DBAL-252] [GH-131] [mysqli] Added mysqli driver to travis tests. Created: 07/Apr/12  Updated: 16/Apr/12  Resolved: 16/Apr/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 kimhemsoe:

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

Message:



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

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





[DBAL-249] Enable caching for fetch type FETCH_COLUMN Created: 05/Apr/12  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: Aigars Gedroics Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

If results are requested using fetch method FETCH_COLUMN, and the cache is used, the exception is raised:

Invalid fetch-style given for caching result


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

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

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





[DBAL-248] [GH-127] Fix Statement class passing bound objects to SQL logger Created: 04/Apr/12  Updated: 04/May/12  Resolved: 04/May/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 jimcottrell:

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

Message:

This commit saves converted parameter values in bindValue() so the later call to the SQL logger in execute() will not pass bound objects without type information.



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

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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





[DBAL-243] setCharset raises an error when using pdo_sqlite Created: 25/Mar/12  Updated: 05/Jul/12  Resolved: 05/Jul/12

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

Type: Bug Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I attempt to use setCharset("utf8") with pdo_sqlite, this fails.

I know that pdo_sqlite doesn't support SET NAMES utf8, however, this should be caught by the driver (like: throwing a NotSupportedException) or simply ignore setCharset (mainly because if you allow the user to choose their backend, developers don't need to introduce special cases for driver handling).



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

Removed Connection#setcharsetSQL() - Use DriverManager::getConnection(array('charset' => 'UTF8', ...)); instead.





[DBAL-241] Add fetchAll(PDO::FETCH_COLUMN) support to OCI8 driver Created: 24/Mar/12  Updated: 24/Mar/12  Resolved: 24/Mar/12

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

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


 Description   

See https://github.com/doctrine/dbal/pull/52






[DBAL-238] Disable MultipleActiveResultSets in SQL Server (pdo_sqlsrv) not possible Created: 19/Mar/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.2, 2.3
Security Level: All

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


 Description   

http://msdn.microsoft.com/en-us/library/ee376925%28v=sql.90%29.aspx






[DBAL-223] Add DBAL TableGenerator Created: 13/Feb/12  Updated: 13/Feb/12  Resolved: 13/Feb/12

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

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

Issue Links:
Dependency
is required for DDC-450 Add TableGenerator Implementation Reopened

 Description   
/**
 * Table ID Generator for those poor languages that are missing sequences.
 *
 * WARNING: The Table Id Generator clones a second independent database
 * connection to work correctly. This means using the generator requests that
 * generate IDs will have two open database connections. This is necessary to
 * be safe from transaction failures in the main connection. Make sure to only
 * ever use one TableGenerator otherwise you end up with many connections.
 *
 * TableID Generator does not work with SQLite.
 *
 * The TableGenerator does not take care of creating the SQL Table itself. You
 * should look at the `TableGeneratorSchemaVisitor` to do this for you.
 * Otherwise the schema for a table looks like:
 *
 * CREATE sequences (
 *   sequence_name VARCHAR(255) NOT NULL,
 *   sequence_value INT NOT NULL DEFAULT '1',
 *   sequence_increment_by INT NOT NULL DEFAULT '1',
 *   PRIMARY KEY (table_name)
 * );
 *
 * Technically this generator works as follows:
 *
 * 1. Use a robust transaction serialization level.
 * 2. Open transaction
 * 3. Acquire a read lock on the table row (SELECT .. FOR UPDATE)
 * 4. Increment current value by one and write back to database
 * 5. Commit transaction
 *
 * If you are using a sequence_increment_by value that is larger than one the
 * ID Generator will keep incrementing values until it hits the incrementation
 * gap before issuing another query.
 *
 * If no row is present for a given sequence a new one will be created with the
 * default values 'value' = 1 and 'increment_by' = 1
 *
 * @author Benjamin Eberlei <kontakt@beberlei.de>
 */


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

Implemented under the DDC-450 label, will get into ORM through this implementation.





[DBAL-224] Allow drop index and pk from table instance Created: 13/Feb/12  Updated: 13/Feb/12  Resolved: 13/Feb/12

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

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


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

Implemented





[DBAL-222] Add Azure Platform Created: 13/Feb/12  Updated: 13/Feb/12  Resolved: 13/Feb/12

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

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


 Description   

SQL Azure has some platform specific SQL on top of SQL Server 2008 mainly to support Federations



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

Implemented.





[DBAL-220] Some platforms require specific index handling Created: 13/Feb/12  Updated: 29/Jan/13  Resolved: 13/Feb/12

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

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


 Description   
  • SQL Server/Azure for example requires strict differentiation between CLUSTERED/NON-CLUSTERED indexes.
  • MySQL can create full text indexes
  • etcetc.


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

Implemented.

Comment by Benjamin Eberlei [ 13/Feb/12 ]

SQL Server can now create clustered or non-clustered indexes like:

$table->setPrimaryKey(array("id"));
$table->getIndex('primary')->addFlag('nonclustered');
$table->addIndex(array("column1"), "name");
$table->getIndex("name")->addFlag("clustered");
Comment by Steve Müller [ 29/Jan/13 ]

Is there any way to define the flags via class metadata? Shouldn't there be the possibility to pass the flags to a class metadata index/id definition?





[DBAL-216] Add ext/sqlsrv support Created: 05/Feb/12  Updated: 13/Feb/12  Resolved: 13/Feb/12

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

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


 Description   

Currently we only have support for PDO_SQLSRV, however some of the Azure/Advanced functionality strictly needs the sqlsrv extension.



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

Implemented.





[DBAL-208] Uniqueidentifier MSSQL type is not supported in DBAL Created: 23/Jan/12  Updated: 24/Mar/12  Resolved: 24/Mar/12

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

Type: Improvement Priority: Major
Reporter: ross neacoders Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows 7 64x
MS SQL 2008 R2 Express edition
Doctrine2, Doctrine-DBAL and Doctrine-Common are on current [master]



 Description   

My Symfony2 projects currently use main trunks of the Doctrine projects, the latest release merge into this branch was 2.2.0-BETA2, that's why I mentioned it in"Affected versions". Sorry if mistaken.

I would like to report that MSSQL Driver/Platform still does not support the 'uniquidentifier' field type of MSSQL.

Trying to introspect the database with
php app/console doctrine:mapping:import MMPTestDBBundle annotation
we get the error

[Doctrine\DBAL\DBALException]
  Unknown database type uniqueidentifier requested, Doctrine\DBAL\Platforms\SQLServer2008Platform may not support it.

There is a related issue, opened and fixed in Doctrine1 project
http://www.doctrine-project.org/jira/browse/DC-253

Going to fix this issue in the same way. Any help greatly appreciated.






[DBAL-479] Doctrine2 schema-tool:update doesn't re-create foreign keys on entity change Created: 07/Jan/12  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

Type: Bug Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1585 Doctrine2 doesn't check for the corre... Resolved

 Description   

I have changed a @ManyToOne relation to another entity. My workflow was this:

  • Having @ManyToOne(targetEntity="Entity\EntityA") in the source
  • Creating the database schema
  • Changing @ManyToOne(targetEntity="Entity\EntityA") to @ManyToOne(targetEntity="Entity\EntityB")
  • Calling doctrine orm:schema-tool:update

orm:schema-tool:update doesn't notice that and doesn't re-create the FK on MySQL and PostgreSQL (haven't tested others).



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

Does this use the same variable or does the many to one variable name change?

Comment by Timo A. Hummel [ 09/Jan/12 ]

Yes, same variable name. For the real-world change, see:

https://github.com/partkeepr/PartKeepr/commit/1cf520f6433dd4d14785a7791a6efe6ab67cc47c

Comment by Timo A. Hummel [ 27/May/12 ]

Any news of this issue?

This is actually not a duplicate of DDC-1585.

Comment by Timo A. Hummel [ 27/May/12 ]

13:32:46 < beberlei> it is a DBAL issue, so you should start replicating it there
13:33:10 < beberlei> i mean, have a look at how the DBAL SchemaDiff looks like in that case, and why it creates the sql wrong
13:33:19 < beberlei> probably the comperator misses something

Comment by Timo A. Hummel [ 29/May/12 ]

I finally found the spot where the check is missing:

Comparator::diffForeignKey misses to compare the foreign table name, which can be added as this:

if ($key1->getForeignTableName() != $key2->getForeignTableName()) {
       return true;
}
Comment by Joshua Smith [ 17/Oct/12 ]

I've looked through the bugs in the DBAL project that reference the Comparator and I can't find one for this issue.

Has one been created for it that I have missed?

Also, I tried adding the suggested code into my project and schema-tool:update generated SQL to drop and recreate every foreign key relationship. I applied those changes and ran schema-tool:update again, expecting to get the normal "nothing to update" message. What I got was SQL to drop and recreate every foreign key relationship. Again.

Tracing the code revealed that (in one case) $key1->getForeignTableName() was returning 'user' and $key2->getForeignTableName() was returning 'User'. All of the foreign key comparisons followed the same pattern. I applied strtolower() to each of them before the comparison and now things seem to behave as I expect, but I don't know how portable my solution is.

if (strtolower($key1->getForeignTableName()) != strtolower($key2->getForeignTableName())) {
    return true;
}

I think applying strtolower() like this is OK since something similar is done when comparing local columns and foreign columns earlier in Comparator::diffForeignKey().

Comment by Benjamin Eberlei [ 01/Apr/13 ]

This was fixed in https://github.com/doctrine/dbal/commit/d7908fee and is part of Doctrine 2.3





[DBAL-191] GH-85: [WIP] Drizzle Support Created: 25/Dec/11  Updated: 22/Sep/12  Resolved: 22/Sep/12

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/dbal/pull/85

Drizzle platform support
Driver is using pdo_mysql

All DBAL tests complete except PortabilityTest.



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

Mark as new feature

Comment by Kim Hemsø [ 20/Sep/12 ]

This one have been solved and is in release 2.3

take a look at dbal-100 aswell, also about drizzle.

Comment by Benjamin Eberlei [ 22/Sep/12 ]

Was already fixed way ago





[DBAL-166] Table Encoding on generation table creation query Created: 14/Sep/11  Updated: 01/Apr/12  Resolved: 01/Apr/12

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

Type: Bug Priority: Major
Reporter: Punin Nicolay G. Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

mysql


Attachments: File docrine-dbal-patch.php    

 Description   

Can not set charset options for table creation.
Now I am fix thix problem in patch.
File: doctrine-dbal/lib/Doctrine/DBAL/Schema/Schema.php

#!/usr/bin/php
<?php
/**

  • Doctrine DBAL Patch
  • fix table creation query encode
  • (c) _Nicolay
    */
    system ('cp ./vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/Schema.php ./vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/Schema.php.Orig');

$data = file_get_contents('./vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/Schema.php');
$data = str_replace("new Table(\$tableName);",
"new Table(\$tableName,array(),array(),array(),0,array('charset'=>'utf8','collate'=>'utf8_general_ci'));",
$data);
file_put_contents('./vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/Schema.php', $data);



 Comments   
Comment by Stepan Tanasiychuk [ 20/Oct/11 ]

Guys, it's real problem for me too! (:

My test suite (in symfony2 project) always creates tables with "latin1_swedish_ci" collation. I want set "utf8_general_ci". But I don't want do it's in mysql.ini.

I tried setting it in MysqlSessionInit __construct, but it's not solved my problem.

In MySqlPlatform I found next code (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L420):

        if (isset($options['charset'])) {
            $optionStrings['charset'] = 'DEFAULT CHARACTER SET ' . $options['charset'];
            if (isset($options['collate'])) {
                $optionStrings['charset'] .= ' COLLATE ' . $options['collate'];
            }
        }

But any options don't set in this call
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/SchemaTool.php#L133

Comment by Benjamin Eberlei [ 01/Apr/12 ]

Implemented this as a new feature on Schema. Also defaulting to UTF-8 now.





[DBAL-161] Character Set of Database not UTF-8 Created: 07/Sep/11  Updated: 20/Nov/12  Resolved: 05/May/12

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

Type: Bug Priority: Major
Reporter: Hari K T Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu



 Description   

Hi Guys,

I was working with symfony command line and created the database with the app/console doctrine:create:database

Though the characterset I specified was UTF-8 , it created Latin character set .

@elliot was right too, the create database is not using any character set https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L328

You can see the issue created at https://github.com/symfony/symfony/issues/2044 and later Fabien confirmed the bug is related to Doctrine .

I am not sure its a Bug or a feature I am asking .

Thanks



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

Yes these are not connected, however we changed the default collation to UTF-8 for DBAL 2.3

Comment by Ivan Borzenkov [ 20/Nov/12 ]

not fixed or broken now
doctrine:create:database still create database whis latin1 charset

https://github.com/doctrine/DoctrineBundle/issues/49





[DBAL-153] Github-PR-48 by phekmat: Added a regression test case for recently fixed PostgreSQLSchemaManager bug Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

Type: Improvement 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

{username}

:

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

Message:

Regression test for the following change: https://github.com/doctrine/dbal/commit/2434d95aab231273eea8fb555155e9e9c195bcc9



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

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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





[DBAL-100] Add Drizzle Support Created: 16/Mar/11  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

Drizzle is out, we should add support for the Dialect.

http://docs.drizzle.org/mysql_differences.html



 Comments   
Comment by Andreas Streichardt [ 22/Dec/11 ]

i have created some hackish fork and the whole testsuite is working already:

https://github.com/m0ppers/dbal

Still WIP but may be a start. I think the C extension is not really ready yet either. When i find time i will most likely have a look at it.

Comment by Benjamin Eberlei [ 22/Dec/11 ]

Can you branch it into something, like git checkout -bDrizzle then push it to your repo and open a Pull Request? Thats way easier to review and discuss.

Comment by Steve Müller [ 24/Jun/13 ]

Isn't this already implemented?

Comment by Kim Hemsø [ 02/Aug/13 ]

Yes it is, long time ago. Well.. difference is that Andreas here is using the now (dead?) native drizzle ext. Where dbal is using pdo for mysql.





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-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-178] Unknown column type requested Created: 02/Nov/11  Updated: 05/Aug/13  Resolved: 26/Jun/12

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

Type: Improvement Priority: Minor
Reporter: Francois Mazerolle Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

OSX ( Using Symfony2 )



 Description   

When I run doctrine:schema:create, doctrine throw the following exception:
[Doctrine\DBAL\DBALException]
Unknown column type requested.

( Note: their is 2 spaces between type and requested )

The problem with this error message is how much it's unspecific. Event with -v, I still have no clue about that type is wrong, and what file is concerned.
So basically, I have to manually look at all my mapping files, one by one.

Also note that doctrine:mapping:info return all OK.



 Comments   
Comment by Denny Swindle [ 21/Nov/11 ]

Ironically, this same issue has recently started happening for me as well. It just started randomly over the weekend. Same exact issue (with 2 spaces between type and requested). For me, it happens when using Doctrine\ORM\EntityManager->find() on a valid entity.

#0 /doctrine-2.1.2/Doctrine/DBAL/DBALException.php(81): Doctrine\DBAL\DBALException::unknownColumnType()
#1 /doctrine-2.1.2/Doctrine/DBAL/Types/Type.php(140): Doctrine\DBAL\DBALException::unknownColumnType()
#2 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php(84): Doctrine\DBAL\Types\Type::getType()
#3 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php(43): Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->_hydrateRow()
#4 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(99): Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->_hydrateAll()
#5 /doctrine-2.1.2/Doctrine/ORM/Persisters/BasicEntityPersister.php(581): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll()
#6 /doctrine-2.1.2/Doctrine/ORM/EntityRepository.php(130): Doctrine\ORM\Persisters\BasicEntityPersister->load()
#7 /doctrine-2.1.2/Doctrine/ORM/EntityManager.php(350): Doctrine\ORM\EntityRepository->find()

Comment by Gediminas Morkevicius [ 21/Jan/12 ]

hi, seems like doctrine does not clean cache fully.

in my case I'm using APC cache
run: in php *apc_clear_cache('user');*

it should work fine now

PS.:
running cache clearing commands, does not help.

doctrine:cache:clear-metadata Clears all metadata cache for a entity manager
doctrine:cache:clear-query Clears all query cache for a entity manager
doctrine:cache:clear-result Clears result cache for a entity manager

Comment by Francois Mazerolle [ 23/Jan/12 ]

Hi,

@gediminas : I don't have the error anymore so I can't test, but it's nice if there's a solution to fix it.

However, this error is problematic as it's anti-verbose.
There's is no indication of a cache problem in the error message. It try to point out to a field, and that field is not even displayed in the error.
I hope someone will be able to fix the error so that's it become a useful error, like by following some sort of guideline:

http://www.useit.com/alertbox/20010624.html

I don't want to troll or anything, but as I'Ve started using doctrine2 with symfony2, the MAJOR problem I've encountered what bad error message that was leaving me lost. Often I had -v, find the file where the error occurred, look at the code, understand by myself what's wrong and attempt to fix it. This is counter-productive and really show that the exception message doesn't follow most error message guide line. For sure, we're not end-users, but we're "programmer-user" that use the system, and this "title" come with a knowledge that is not the same as we could expect of a core-developer, for example.

I hope this message was constructive.

Comment by Benjamin Eberlei [ 26/Jun/12 ]

Improved this error message alot and also changed some regarding reverse engineering of custom types (where this error often occured):

You can now implement Type#getMappedDatabaseTypes(AbstractPlatform $platform); on your custom type and return a list of database types that this doctrine type maps to.

Comment by Almog Baku [ 05/Aug/13 ]

this bug is still happening to me.. but its works as excepted within `schema:create` and throw error on `schema:update` or `schema:drop`

I using doctrine with symfony





[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-229] oic8 oci_pconnect is not surported Created: 02/Mar/12  Updated: 31/Mar/12  Resolved: 31/Mar/12

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

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


 Description   

public function __construct($username, $password, $db, $charset = null, $sessionMode = OCI_DEFAULT)
{
if (!defined('OCI_NO_AUTO_COMMIT'))

{ define('OCI_NO_AUTO_COMMIT', 0); }

$this->_dbh = @oci_connect($username, $password, $db, $charset, $sessionMode);
if (!$this->_dbh)

{ throw OCI8Exception::fromErrorInfo(oci_error()); }

}

How can i use oci_pconnect in oic8 driver?



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

Implemented.

There are now two new options in the oci8 connection:

1. $param['pooled'] to use the POOLED connection option
2. $param['persistent'] to use persistent connections.





Generated at Wed Oct 01 22:28:59 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.