[DBAL-1224] [GH-851] Change MySQL defaults from broken utf8 to fixed utf8mb4 Created: 04/May/15  Updated: 04/May/15

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 DHager:

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

Message:

This is a conservative echo of https://github.com/doctrine/dbal/pull/317 .

Essentially MySQL's `uft8` character set is broken and does not support full UTF-8, and a better alternative, `utf8mb4` has existed for about five years now. Insofar as Doctrine has a MySQL default configuration, `utf8mb4` is a better choice.






[DBAL-1223] Doctrine migration diff not using column name annotation in traits Created: 04/May/15  Updated: 04/May/15  Resolved: 04/May/15

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

Type: Bug Priority: Major
Reporter: Mathieu Dumoulin Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: None
Environment:

PHP 5.6, latest composer version and latest version of Doctrine-Bundle for Symfony 2



 Description   

We are using a trait to define fields for "created_at" and "updated_at" in our entities and just realized that the:

use Doctrine\ORM\Mapping as ORM;
/*

  • @ORM\Column(name="created_at", type="datetime", nullable=true)
    */

is not enforced correctly when updating the database. It creates the field as "createdAt" in our database version 2 and the migration scripts to migrate version 1 to version 2 created provide the same behavior and try to rename the correct database version 1 field "created_at" to "createdAt" which is wrong.

I've tested this by placing the same code in an entity not using the trait and running diff now creates the field in the database using "created_at".



 Comments   
Comment by Mathieu Dumoulin [ 04/May/15 ]

Cancel this, we found the problem to be localized to our install, code was incorrect in several bundles and refered to a completely remote class...





[DBAL-1207] Schema Update Issue with DBAL 2.5 Binary Type Created: 24/Apr/15  Updated: 04/May/15

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Gurrola Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Ubuntu 14.04.2 LTS, Apache 2.4.7, PHP 2.5.9, MySQL 5.5, Symfony 2.6.6



 Description   

Every time I run a doctrine:schema:update command within Symfony, using DBAL 2.5, it tries to execute this SQL Query, every single time:

SQL Query
ALTER TABLE user_sessions CHANGE sess_id sess_id VARBINARY(128) NOT NULL;

The PHP Annotations I am using for this column is as follows:

Binary Column
/**
 * @var string
 *
 * @ORM\Column(name="sess_id", type="binary", length=128, nullable=false)
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 */
private $sessId;

It seems the binary type is somehow registering a change even though no change has actually been made. I updated to DBAL to 2.5 before getting the binary type supported by the doctrine:schema:update command.

Thanks in advance for any assistance in squashing this odd bug.

--Alex Gurrola






[DBAL-1222] [GH-850] Allow to specify a charset and collation per column for Mysql Created: 03/May/15  Updated: 03/May/15

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 Freeaqingme:

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

Message:






[DBAL-1221] Wrong dsn when using postgresql with pdo Created: 02/May/15  Updated: 02/May/15  Resolved: 02/May/15

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

Type: Bug Priority: Major
Reporter: Karim Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: dbal, dsn, postgresql
Environment:

Symfony 2.6 on Linux Fedora 21 using PHP 5.6.8


Issue Links:
Duplicate
duplicates DBAL-1215 [GH-844] template1 as default databas... Resolved

 Description   

When I trying to create database using command line from Symfony framework, an error occurs :
[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[08006] [7] FATAL: database « myUserName » does not exists.

I tried to check what is wrong and I found that if in the class Doctrine\DBAL\Driver\PDOPgSql\Driver, in _constructPdoDsn method, i explicitly set the dbname like : $params['dbname'] = "myDb"; , it works.



 Comments   
Comment by Steve Müller [ 02/May/15 ]

Duplicate of DBAL-1215.





[DBAL-1215] [GH-844] template1 as default database for PostgreSQL Created: 29/Apr/15  Updated: 02/May/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbname, pdo_pgsql, pgsql, postgresql, template1

Issue Links:
Duplicate
is duplicated by DBAL-1221 Wrong dsn when using postgresql with pdo Resolved

 Description   

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

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

Message:

Fixes (including but not limited to) https://github.com/doctrine/DoctrineBundle/issues/402 by connecting by default to 'template1' instead of the database with the same name as the user (PostgreSQL default in case of no dbname).



 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1199] [GH-837] Revert the addition of the wrong bin script Created: 15/Apr/15  Updated: 01/May/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: cli, composer, tools


 Description   

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

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

Message:

The bin/doctrine-dbal.php file is not an executable file. Adding them as a bin in composer.json means that any composer install will trigger changes in the source when using symlinks because of the chmod. This makes things a pain when installing from source.
Thus, there is no valid reason to add it. It is absolutely not necessary when using a composer install. The issue requesting it previously is actually an issue in Laravel which replaces the proxy file/symlink generated by Composer with a copy of the original file, which of course cannot work because of paths used in require. But copying a second file does not help for that (unless in very specific cases). It only moves the issue until the next require call.



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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

Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1220] [GH-849] Fix dropping database with active connection on PostgreSQL Created: 01/May/15  Updated: 01/May/15

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/849

Message:

PostgreSQL fails to drop a database if there are active connections using that particular database.
This PR closes all active connections before dropping the database if dropping the database failed before.






[DBAL-1153] [GH-805] Allow symfony 3.0 components Created: 22/Feb/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: composer, symfony


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

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

Message:

Tests should tell if any deprecated interfaces of Symfony are used. If not, then the bundle is defacto compatible with 3.0



 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1209] [GH-841] Documentation & code styling fixes Created: 25/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: code-style, cs, phpdoc


 Description   

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

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

Message:

This fixes:

  • incorrect / incomplete / missing PHPdoc
  • wrong case for method names
  • unused imports


 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1197] [GH-835] backport bugfix to avoid fatal error in array_merge during generating the table creation SQL Created: 10/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: create-schema, create-table, sql-collector


 Description   

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

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

Message:

2.5 includes this fix in 1c9fe8df . this pull request is just to backport the bugfix without further changes.

i verified on https://github.com/jackalope/jackalope-doctrine-dbal/pull/258 that this change indeed fixes the issue - but i don't know how to write a test for this.



 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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

Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1219] [GH-848] [DBAL-1219] Add missing functional driver test cases Created: 30/Apr/15  Updated: 30/Apr/15

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/848

Message:






[DBAL-1218] [GH-847] [DBAL-1217] Fix retrieving the database name connected to for SQL Anywhere Created: 30/Apr/15  Updated: 30/Apr/15

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/847

Message:

When connecting to SQL Anywhere without `dbname` parameter set, the underlying driver emits a `undefined index "dbname"` when trying to retrieve the database name connected to via `Doctrine\DBAL\Driver::getDatabase()`.
This PR implements the "live" retrieval of the current database as seen in other drivers already.






[DBAL-1217] [GH-846] Fix retrieving the database name connected to for SQL Server Created: 30/Apr/15  Updated: 30/Apr/15

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/846

Message:

When connecting to SQL Server without `dbname` parameter set, the underlying driver emits a `undefined index "dbname"` when trying to retrieve the database name connected to via `Doctrine\DBAL\Driver::getDatabase()`.
This PR implements the "live" retrieval of the current database as seen in other drivers already.






[DBAL-1216] [GH-845] Dbal 1215 Created: 30/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1190] [GH-829] Pgsql connection test with charset parameter Created: 02/Apr/15  Updated: 30/Apr/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: charset, client_encoding, pdo_pgsql, pgbouncer, pgsql, postgresql, testing


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR adds 2 tests for connecting to pgsql via PDOPgSql, while using a charset parameter.

Related to #828, #823



 Comments   
Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-569] json_array/simple_array columns constantly updated by schema-tool Created: 25/Jul/13  Updated: 29/Apr/15  Resolved: 18/Dec/13

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

Type: Bug Priority: Minor
Reporter: Jonathan Campbell Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: schematool
Environment:

IIS 7.5, PHP 5.4.11, SQL Server 2012


Issue Links:
Reference
is referenced by DBAL-632 MSSQL Diff Resolved

 Description   

I have the following columns defined:

    /**
     * @ORM\Column(type="json_array")
     * @var array
     */
    protected $feedKey = array();

    /**
     * @ORM\Column(type="simple_array")
     * @var array
     */
    protected $privileges = array('none');

Every time I run " .\vendor\bin\doctrine-module orm:schema-tool:update --dump-sql", these two columns are "updated":

ALTER TABLE RoleResource ALTER COLUMN [privileges] VARCHAR(MAX) NOT NULL;
ALTER TABLE FeedEntity ALTER COLUMN feedKey VARCHAR(MAX) NOT NULL

When I browse to that table in Microsoft SQL Server Management Studio, the column definitions are already "privileges (varchar(max), not null)" and "feedKey (varchar(max), not null)".

The repeated update from schema-tool continues even after I let it run with --force.



 Comments   
Comment by Steve Müller [ 25/Nov/13 ]

There is WIP PR to support column comments in SQL Server which resolves this issue:

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

Comment by Doctrine Bot [ 18/Dec/13 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/28264a15a404496155d84a0abfa3404d01302905

Comment by Grégoire Paris [ 29/Apr/15 ]

I'm having the same bug with postgresql and a json_array to array migration. Should this bug be reopened and made more generic or should I create a new one ?

A workaround for this bug is to simply delete the field. An additional line is generated (it adds an SQL comment).





[DBAL-1213] [GH-843] fix TypeHinting for method parameter 'convertToPHPValueSQL' Created: 28/Apr/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: parameter, type, type-hinting


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/15 ]

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

Comment by Doctrine Bot [ 29/Apr/15 ]

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

Comment by Marco Pivetta [ 29/Apr/15 ]

Closing since it is a BC break





[DBAL-1214] MySQL has gone away using ImportCommand Created: 29/Apr/15  Updated: 29/Apr/15

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

Type: Bug Priority: Major
Reporter: Sylvain Filteau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Importing a fairly large SQL file (a MySQL dump) fails with a MySQL has gone away error.

When reading the ImportCommand code, I see that this issue is already "fixed" by checking if the connection is an instance of `\Doctrine\DBAL\Driver\PDOConnection`.

The problem is that I don't see how the connection could be an instance of this class since it doesn't extend `\Doctrine\DBAL\Connection`.

If I'm wrong, then I don't know how to configure my connection to extend the PDOConnection class. Thanks for your help on that






Generated at Tue May 05 08:20:22 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.