[DBAL-1016] [GH-700] [DBAL-1016] Fix explicitly quoted table identifiers in ALTER TABLE statements Created: 20/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, quoting, schemadiff, schematool


 Description   

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

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

Message:

Another improvement to the neverending quotation issues.
This patch fixes explicitly quoted table identifiers in `ALTER TABLE` statements.
Additionally some minor fixes had to be applied such as misc fixing of foreign key constraint statements order in the sequence of statements necessary to alter a table.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1015] [GH-699] Adds support for setting the charset in SQLSrv Created: 20/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: charset, dsn, encoding, mssql, sqlserver


 Description   

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

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

Message:

As seen here => http://technet.microsoft.com/en-us/library/cc626307(v=sql.105).aspx



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1014] [GH-698] [DBAL-1014] Support HHVM mysqli driver Created: 20/Oct/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

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

Type: Improvement Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hhvm, mysqli


 Description   

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

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

Message:

Adds support for HHVM's mysqli driver implementation.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DBAL-1013] [GH-696] [DBAL-1013] Fix table diff's new name if it is not set Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, schematool


 Description   

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

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

Message:

The `TableDiff` should not wrap `TableDiff::$newName` into an `Identifier` if it is not set.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1012] [GH-695] [Documentation] Add missing quotes at the end of literal strings Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 17/Oct/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, documentation


 Description   

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

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



 Comments   
Comment by Steve Müller [ 17/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/d400586168bfc19b8fe84d7cf9f432b54ce21306

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1011] [GH-694] [DBAL-1011] Fix column comments containing string literal chars on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/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: ddl, escaping, schematool


 Description   

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

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

Message:

When trying to create or update a column with a comment containing the string literal quote character `'`, SQL generation is invalid and fails on execution. This patch now quotes the particular comment to come around this issue.






[DBAL-1010] [GH-693] [DBAL-1010] Fix renaming column with default value on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/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: ddl, schematool

Issue Links:
Reference
relates to DBAL-830 [GH-539] unit test added for altering... Resolved

 Description   

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

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

Message:

Doctrine throws a fatal error on renaming a column with a default value set because of nested `Identifier` objects as old column name.
This issue was introduced by https://github.com/doctrine/dbal/pull/672.



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-1009] [GH-692] [DBAL-1009] Fix column comment lifecycle Created: 16/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: comments, ddl, schematool


 Description   

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

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

Message:

The lifecycle of a column comment is not correct.
The comparator would not detect added comments. Also platforms did not handle the licecycle consistently.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1008] [GH-691] Add test case for #688 Created: 16/Oct/14  Updated: 21/Oct/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 malukenho:

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

Message:



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1007] [GH-681] Fixed expanding positional parameters which do not start from 0 Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: sql-parser





[DBAL-1006] [GH-690] Backport [DBAL-717] Fix bug in MasterSlaveConnection with keepSlave option and switch back after transaction. Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-335 Is MasterSlaveConnection implemented ... Resolved
depends on DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-1005] Timezones of DateTime instances are ignored when persisting dates Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

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

Type: Bug Priority: Major
Reporter: Brent Shaffer Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

When a DateTime instance, e.g. "2011-02-16 00:00:00 America/New_York" is written into the DB, the timezone is ignored and only "2011-02-16" is persisted. When fetching the date, it is written into a DateTime with the server's timezone, resulting in for example "2011-02-16 00:00:00 Europe/Berlin" which is not correct!

To fix this issue, Doctrine should convert dates to the server's timezone (if their own timezone differs) before persisting them or before executing queries containing DateTime instances.



 Comments   
Comment by Brent Shaffer [ 15/Oct/14 ]

I would like to reopen this issue - Doctrine is expecting the incoming DateTime objects to have the system's default_timezone. If they do NOT use the default timezone (let's say they, instead use UTC), then the date is saved in the format of the default timezone anyway, and upon hydration, the UNIX timestamp changes.

I don't see how this could ever be considered expected behavior. Doctrine is essentially modifying the timestamp being persisted.

Doctrine should set the timezone of the DateTime object prior to persistence using the date_default_timezone_get() method. Either that, or the persisted string should contain the timezone identifier of the initial DateTIme object.

Comment by Marco Pivetta [ 15/Oct/14 ]

See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/working-with-datetime.html

The current DateTime type completely ignores timezones and we will keep it like that for now.

Comment by Brent Shaffer [ 15/Oct/14 ]

@Marco thank you for your quick reply. Can you help me understand why the decision was made to expect the timezone to be the default instead of just setting it to be that way before persistence? It seems like all these woes could have been easily avoided...

Comment by Marco Pivetta [ 15/Oct/14 ]

Brent Shaffer it was indeed a mistake to not use stricter rules on DateTime instances, but due to the amount of code depending on this behavior right now, we cannot change the Doctrine\DBAL\Types\DateTimeType anymore.

Instead, we may consider introducing a new UTC-based datetime-type for 3.x.

A change is not going to be applied on existing logic.





[DBAL-1004] [GH-689] [DBAL-1004] Fix generating COMMENT ON COLUMN statements for quoted identifiers Created: 15/Oct/14  Updated: 19/Oct/14

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

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


 Description   

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

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

Message:

Fixes SQL generation for `COMMENT ON COLUMN` statements on all platforms.
See also: https://github.com/doctrine/dbal/pull/687#issuecomment-59203122



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1003] [GH-688] Fixed closing a connection Created: 14/Oct/14  Updated: 14/Oct/14

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

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

Issue Links:
Dependency
is required for DBAL-997 [GH-685] Update MasterSlaveConnection... Resolved

 Description   

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

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

Message:

The inner connection should be unreferenced, but the property should not be removed from the object

Refs https://github.com/doctrine/dbal/pull/685



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

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





[DBAL-1002] [GH-687] [DBAL-1001] Fix NULL / NOT NULL clause for column alterations in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
is required for DBAL-1001 NULL / NOT NULL clause always appende... Resolved

 Description   

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

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

Message:

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a `NULL` / `NOT NULL` clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.
See also: https://github.com/doctrine/dbal/pull/676#issuecomment-57643477



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1001] NULL / NOT NULL clause always appended to column alteration declaration in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
depends on DBAL-1002 [GH-687] [DBAL-1001] Fix NULL / NOT N... Resolved
Reference
relates to DBAL-472 Oracle schema modification - incorrec... Resolved

 Description   

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a NULL / NOT NULL clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.



 Comments   
Comment by Marco Pivetta [ 19/Oct/14 ]

Solved in DBAL-1002





[DBAL-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 15/Oct/14

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

Type: Bug Priority: Critical
Reporter: Marcus Malka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, mysql

Attachments: PNG File Screen Shot 2014-10-14 at 10.53.44.png    

 Description   

When trying to create a database via Symfony (tested 2.3, 2.4, 2.5) console using Doctrine, if returns

[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[42000] [1049] Unknown database 'livedb_ci_tco_dev'

This effectively prevents re-creating the database.

I traced the error, it seems database existence is either not checked or not functioning, and it tries to connect to the DB, resulting in an exception. In older versions the trace seemed like it checked if DB exists, and didn't try to connect.

I tested some different commit versions to assess where the bug was introduced - here is my brief list of working/non-working versions.

812dd9d (v.2.5.0-BETA3) fail
61eb1ee fail
3176f51 fail
da43b76 works
ce3a56e works
594e326 works
ba9aa63 (v.2.5.0-BETA2) works

So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51



 Comments   
Comment by Marco Pivetta [ 14/Oct/14 ]

Marcus Malka are you sure that you are running the correct command? If the DB is not there, I would expect an exception.

Comment by Christophe Coevoet [ 14/Oct/14 ]

Marco Pivetta This command is precisely about creating the database when it does not exist yet. I think this failure is related to the guessing of the platform version in DBAL 2.5, which will require connecting to the DB early.

Comment by Marco Pivetta [ 14/Oct/14 ]

Christophe Coevoet the screenshot shows the `drop` command being used

Comment by Marcus Malka [ 14/Oct/14 ]

I tested with multiple commands, mainly drop and create were most common.

The difference is in the error that gets produced with the different commits applied - other one gives the "The database is not there" kind of error you would expect. The other version gives an "can't do the operation because I can't connect to the database" even when you try to create it, and gives a similar "can't drop the database because I can't connect to the database" kind of error, which still says it tries to do something weird. My screenshot could've been taken from the create-command too, the error was identical.

I should have a breaking composer.json file in my version control on another machine. I'll try to add that later to facilitate debugging.

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

Christophe Coevoet you are right, that DBAL now connects early if you request the database platform but that should not be an issue as you may not specify a non-existing database name when connecting to creating a new database, anyways. And as far as I can see the CreateDatabaseDoctrineCommand even explicitly unsets the database name in the connection params here: https://github.com/doctrine/DoctrineBundle/blob/master/Command/CreateDatabaseDoctrineCommand.php#L71-L80 for a "temporary" connection.
Dropping a database still should require the database to be existent so connecting to it before dropping should be fine or am I missing something here?

Comment by Marcus Malka [ 15/Oct/14 ]

@Steve Muller - is it tries to create the connection and creates an error also when the database is not supposed to be there, for ex. in create action. Effectively breaking createDatabase command.

When I traced the code, it seemed to go in to the platform version checking, and seemed like it just didn't realize early enough that the DB isn't there (that was my guess - I don't know doctrine internals well enough to say if that's how it's planned to work or not).





Generated at Tue Oct 21 05:22:00 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.