[DBAL-1241] Comparator generates wrong result if using database_name.table_name notation Created: 28/May/15  Updated: 28/May/15

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

Type: Bug Priority: Major
Reporter: Pavlo Chipak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schematool
Environment:

Mysql 5.6.21, PHP 5.6.3, Windows



 Description   

At fist created issue in migrations https://github.com/doctrine/migrations/issues/258 but was referenced here.

I'm using Symfony2. In entities schemas configs I'm using dot notation in table names (database_name.table_name) for cross-database joins. When I create migration, there are no deletes of created foreign keys in down() method. Example (some unnecessary code removed):

    public function up(Schema $schema)
    {
        $this->addSql('CREATE TABLE import.article (id INT AUTO_INCREMENT NOT NULL, edition_id INT DEFAULT NULL, title VARCHAR(255) NOT NULL, subtitle LONGTEXT NOT NULL, theme VARCHAR(255) NOT NULL, bar VARCHAR(255) NOT NULL, text LONGTEXT NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_71D0368461220EA6 (creator_id), INDEX IDX_71D036846995AC4C (editor_id), INDEX IDX_71D0368474281A5E (edition_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.author (id INT AUTO_INCREMENT NOT NULL, article_id INT DEFAULT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_8B81B94F61220EA6 (creator_id), INDEX IDX_8B81B94F6995AC4C (editor_id), INDEX IDX_8B81B94F7294869C (article_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.document (id INT AUTO_INCREMENT NOT NULL, edition_id INT DEFAULT NULL, title LONGTEXT NOT NULL, number VARCHAR(255) NOT NULL, theme VARCHAR(255) NOT NULL, department VARCHAR(255) NOT NULL, adoptedAt DATETIME NOT NULL, type INT NOT NULL, text LONGTEXT NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_961EE31A61220EA6 (creator_id), INDEX IDX_961EE31A6995AC4C (editor_id), INDEX IDX_961EE31A74281A5E (edition_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.edition (id INT AUTO_INCREMENT NOT NULL, periodical_id INT DEFAULT NULL, publication_id INT DEFAULT NULL, region_id INT DEFAULT NULL, issue INT NOT NULL, number INT NOT NULL, publishedAt DATETIME NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_DB7B20FD61220EA6 (creator_id), INDEX IDX_DB7B20FD6995AC4C (editor_id), INDEX IDX_DB7B20FD855A7B04 (periodical_id), INDEX IDX_DB7B20FD38B217A7 (publication_id), INDEX IDX_DB7B20FD98260155 (region_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.image (id INT AUTO_INCREMENT NOT NULL, storage_id INT NOT NULL, width VARCHAR(255) NOT NULL, height VARCHAR(255) NOT NULL, material INT NOT NULL, material_type VARCHAR(50) NOT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_E81675F561220EA6 (creator_id), INDEX IDX_E81675F56995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.periodical (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, alias VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_AF07D39961220EA6 (creator_id), INDEX IDX_AF07D3996995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.publication (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_94AF610261220EA6 (creator_id), INDEX IDX_94AF61026995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.region (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_394C90F161220EA6 (creator_id), INDEX IDX_394C90F16995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('ALTER TABLE import.article ADD CONSTRAINT FK_71D0368474281A5E FOREIGN KEY (edition_id) REFERENCES import.edition (id)');
        $this->addSql('ALTER TABLE import.author ADD CONSTRAINT FK_8B81B94F7294869C FOREIGN KEY (article_id) REFERENCES import.article (id)');
        $this->addSql('ALTER TABLE import.document ADD CONSTRAINT FK_961EE31A74281A5E FOREIGN KEY (edition_id) REFERENCES import.edition (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD855A7B04 FOREIGN KEY (periodical_id) REFERENCES import.periodical (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD38B217A7 FOREIGN KEY (publication_id) REFERENCES import.publication (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD98260155 FOREIGN KEY (region_id) REFERENCES import.region (id)');
    }

    public function down(Schema $schema)
    {
        $this->addSql('DROP TABLE import.article');
        $this->addSql('DROP TABLE import.author');
        $this->addSql('DROP TABLE import.document');
        $this->addSql('DROP TABLE import.edition');
        $this->addSql('DROP TABLE import.image');
        $this->addSql('DROP TABLE import.periodical');
        $this->addSql('DROP TABLE import.publication');
        $this->addSql('DROP TABLE import.region');
    }

This is lost

        $this->addSql('ALTER TABLE import.article DROP FOREIGN KEY FK_71D0368474281A5E');
	$this->addSql('ALTER TABLE import.author DROP FOREIGN KEY FK_8B81B94F7294869C');
        $this->addSql('ALTER TABLE import.document DROP FOREIGN KEY FK_961EE31A74281A5E');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD855A7B04');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD38B217A7');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD98260155');

I had make some research and concluded that in class Doctrine\DBAL\Schema\Comparator in line 91 (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Comparator.php#L91) replacing getShortestName by getName fixes this problem. But I'm sure it's not complete fix of this problem.



 Comments   
Comment by mikeSimonson [ 28/May/15 ]

As I explained to you, your problem only exist because of the order of those delete statement.

Maybe the delete statement could be ordered taking into account the tree of dependencies created by the foreign keys ?





[DBAL-1182] No schema difference detected when changing length of a text field Created: 26/Mar/15  Updated: 26/Mar/15

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

Type: Bug Priority: Major
Reporter: Evan Sheffield Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schema-tool
Environment:

Database: MySQL 5.6



 Description   

I have a text field with a length specified that causes it to be chosen as TINYTEXT in MySQL.

/**  
 * @ORM\Column(name="message", type="text", length=255,  nullable=true)
 */
protected $message;

When I remove the length field from the annotation, I would expect the field to then be interpreted as LONGTEXT as specified in the documentation. However, when I run orm:schematool:update, it says that there is nothing to update.






[DBAL-1132] [GH-786] Fix removing autoincrement column from a primary key Created: 26/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
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: alter-table, autoincrement, mysql, primary-key

Issue Links:
Reference
relates to DBAL-464 MySQL fails when try to drop a primar... Resolved

 Description   

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

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

Message:

https://github.com/doctrine/dbal/pull/430 is only a partial fix for DBAL-464. This adds treating autoincrement columns that get removed when altering a primary key.



 Comments   
Comment by Doctrine Bot [ 01/Feb/15 ]

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

Comment by Doctrine Bot [ 10/Feb/15 ]

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





[DBAL-1116] [GH-774] Added SET and ENUM types for MySQL and fix issue with schema update tool Created: 14/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: ddl, enum, mysql, set, type

Issue Links:
Dependency
is required for DBAL-4 missing column type "enum" Resolved
Reference
relates to DBAL-89 MySqlPlatform does not handle enum a... Resolved

 Description   

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

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

Message:

Set and Enum data types are one of the most popular. However, addition of these data types in the project creates a problem when updating of the database structure.



 Comments   
Comment by Doctrine Bot [ 14/Jan/15 ]

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

Comment by Doctrine Bot [ 14/Jan/15 ]

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

Comment by Marco Pivetta [ 14/Jan/15 ]

See http://stackoverflow.com/a/9057352/347063

ENUM and SET are non-portable types that will not be implemented by the DBAL due to the complexity behind their handling.





[DBAL-1111] [GH-771] Fix unique index exception handling for an index on multiple columns in PHP 5.4 Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, mysql, php-5.4, unique


 Description   

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

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

Message:

In SQLite under PHP 5.4, when I violate a unique index on multiple columns by creating a duplicate record, the PDO Exception thrown is "SQLSTATE[23000]: Integrity constraint violation: 19 columns X, Y are not unique". This PDO exception message is not parsed by the AbstractSQLiteDriver and converted to a UniqueConstraintViolationException as expected, and as happens in PHP 5.5, so only a generic DriverException is thrown, making error handling much harder.

This pull request adds "are not unique" as a string that is checked for in the exception handling code.



 Comments   
Comment by Doctrine Bot [ 11/Jan/15 ]

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

Comment by Doctrine Bot [ 11/Jan/15 ]

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





[DBAL-1091] [GH-755] Update MysqliStatement to support PDO::FETCH_OBJ Created: 23/Dec/14  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: driver, fetch, mysql, mysqli, object


 Description   

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

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

Message:

Return a simple stdClass object if that fetch type is requested.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ddl, decimal, float, mysql, unsinged

Issue Links:
Reference
relates to DBAL-1082 SchemaTool does not generate SQL for ... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1082] SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Daniel Chesterton Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, ddl, decimal, float, mysql, schematool, unsigned
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-1083 [GH-749] [DBAL-1082] Fix SchemaTool d... Resolved

 Description   

The schema update tool does not consider the possibility that MySQL double/float fields can be unsigned.

When running the CLI tool, it recognises that the schemas differ but it doesn't add the appropriate 'UNSIGNED' SQL statement. For example when the database is SIGNED but the entity is marked as UNSIGNED, running the tool with --dump-sql will generate SQL similar to below:

ALTER TABLE tablename CHANGE field field DOUBLE PRECISION NOT NULL;

Running this has no effect on the database and subsequent calls will try to run the same SQL.

I have created a pull request in GitHub which fixes the issue.






[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: detection, mariadb, mysql, platform, version


 Description   

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

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

Message:

Hi,
After upgrading to DBAL 2.5, I got an issue where I could not rename index while migrating because of MariaDB [versioning](http://en.wikipedia.org/wiki/MariaDB#Versioning) which outputs ```10.0.15-MariaDB-1~wheezy ``` as server version.

Because 10.x > 5.7 it loads new features from mysql 5.7 which are not available in mariadb ..



 Comments   
Comment by Doctrine Bot [ 13/Dec/14 ]

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

Comment by Doctrine Bot [ 24/Dec/14 ]

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





[DBAL-1017] Altering a foreign key column is not done properly for MySQL Created: 21/Oct/14  Updated: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, schematool


 Description   

Altering a foreign key column column (for instance to make it not-nullable) or the index of a foreign key does not work on MySQL (to be exact, it does not work on some MySQL setups, but I haven't found the config setting impacting it yet). Making it work requires dropping the foreign key before altering the column/index and readding it after



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

Christophe Coevoet DBAL-732 related?





[DBAL-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 26/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: 1
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).

Comment by Benjamin Eberlei [ 26/Oct/14 ]

This is an issue in DoctrineBundle that only appears in combination with DBAL 2.5.

The problem is Symfony apparently connects to the database in "Container::get" of the connection already. That has to be fixed.





[DBAL-936] Doctrine type not found exception thrown before checking the comment Created: 10/Jul/14  Updated: 11/Jul/14

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

Type: Bug Priority: Major
Reporter: Maxime Veber Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, mysql


 Description   

Here is the piece of code:

$type = $this->_platform->getDoctrineTypeMapping($dbType);

// In cases where not connected to a database DESCRIBE $table does not return 'Comment'
if (isset($tableColumn['comment'])) {
    $type = $this->extractDoctrineTypeFromComment($tableColumn['comment'], $type);
    $tableColumn['comment'] = $this->removeDoctrineTypeFromComment($tableColumn['comment'], $type);
}

The method `getDoctrineTypeMapping` throw an exception if the type is not found. But for example if you have an enum type (see the doctrine cookbook on the subject), the type is setted as comment.

Doctrine throw the exception before having the occasion to get the type via comment.

Here are two solutions:

  • Check for comment before throw the exception
  • Adding the enum type to the doctrine platform and mapping it to string





[DBAL-914] the pdo_mysql driver do not always trhow an error when mysql does Created: 29/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: mikeSimonson Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: mysql

Attachments: Text File 0001-testcase-for-a-bug-in-the-pdo_mysql-driver.patch    

 Description   

When a query get passed to mysql with the pdo_mysql driver and that the query end with a double semicolon "Create table test (test vachar(1));;". Mysql throw an error and stop the execution of the query there (aka in between the first and the second semicolon).
That problem does not exist with the mysqli driver that correctly throw an error.



 Comments   
Comment by Marco Pivetta [ 29/May/14 ]

Doesn't look like a DBAL bug to me.

As far as I know, PDO does not support multiple queries at all, while mysqli does.

Comment by mikeSimonson [ 30/May/14 ]

I suppose it does because if I insert a sql stmt, in between the two semicolon, it gets executed.

I discovered that bug because I had one statement that created 20 tables or so and that someone edited it manually adding the second semicolon by mistake.
And suddenly all that was after that double semicolon wasn't executed anymore.

To be exact, I'd discover the bug using doctrine migration.
I have made a little patch that you can use to test that case.
For the test to run you will need to adapt the credential found in the Doctrine\DBAL\Migrations\Tests\MigrationTestCase file (after applying my patch).
If you replace in that file pdo_mysql with mysqli the dirver correctly issue an error while the other does not.
I have the impression that the root issue is that when mysql is given a statment with 2 semicolons at the end, it throws an error but with an empty errno.
You can test that directly in mysql console.

Thanks

Comment by Marco Pivetta [ 06/Jun/14 ]

See https://bugs.php.net/bug.php?id=61613

Comment by Marco Pivetta [ 26/Jun/14 ]

Bug depends on a php-src bug





[DBAL-899] Escape table name when update schema Created: 07/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Guilherme Santos Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql, orm, schematool


 Description   

I have a table called by load and a field called by release, but in MySQL these are reserved names, and should be called inside of ``. In my annotations I use like that:

@ORM\Table(name="`load`") and
@ORM\Column(name="`release`", length=15)

These lines work good when use ORM, but when I use schema-tool the `` are ignored and it's generate something like that:

ALTER TABLE load CHANGE version release VARCHAR(60) DEFAULT NULL;

And to MySQL it's wrong, the right statement is:

ALTER TABLE `load` CHANGE version `release` VARCHAR(60) DEFAULT NULL;



 Comments   
Comment by Marco Pivetta [ 07/May/14 ]

Guilherme Santos can you verify if master (dbal+orm) fixes this? There has been some work on this issue.

Comment by Steve Müller [ 07/May/14 ]

Moved to DBAL, this is unrelated to ORM.

The table quotation issue has been fixed in 2.5/master in commit: https://github.com/doctrine/dbal/commit/75d35f5809095b37cb7085a9289eca4aa9c6df68

The column quotation issue is weird. There has been a fix in 2.5/master in commit: https://github.com/doctrine/dbal/commit/5156391b5686a2b3bba628bb0bc1fece63409a44 for the OLD column name but according to your example the NEW column name is not quoted. But that is working for ages already.

Can you please verify with the latest master as suggested by Marco Pivetta and maybe post the exact generated SQL by the schema tool?

Comment by Guilherme Santos [ 07/May/14 ]

It was fixed, a lot of index was changed too, but the quotation works!
Thanks...





[DBAL-819] Schema-tools does not work on multiple Oracle's schemas Created: 21/Feb/14  Updated: 28/May/15

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Antoine Descamps Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, mysql, oracle, orm, schematool
Environment:

DB: Oracle 11g



 Description   

The schema-tools, used via the CLI, is not able to detect schema's changes when working on multiple schemas.

For instance, the ORM is configured with a "global" Oracle's user, having permissions on every schemas. To specify which entities belong to which schema, I've prefixed the table name with the corresponding schema.

When trying to do the following command:

orm:schema-tool:update --dump-sql

Doctrine returns me the following message:

Nothing to update - your database is already in sync with the current entity metadata.

If, instead of using the "global" user in the Doctrine's configuration, I set the user of the specific schema I'm trying to generate a table on based from an entity, it works.



 Comments   
Comment by Steve Müller [ 21/Feb/14 ]

Moved this to DBAL for now. It seems to be related to schema prefixed table names not being evaluated in the platforms when generating the SQL for reverse engineering the database schema.

Comment by Steve Müller [ 22/Feb/14 ]

Antoine Descamps Okay after having investigated on this in detail and thinking about the possibilities we have to find a solution for this, I came to the following conclusion:
ORM's schema tool and DBAL's schema introspection are designed to be bound to what Doctrine defines as "database" for each platform. This is the scope of the whole operation. In case of Oracle it is the "user". You cannot break out of this scope in any way as the current DBAL implementation is not designed for a "complete" schema introspection and therefore does not allow it at some points. Fully understanding your concern I am afraid we cannot find a reasonable solution for your use case at this point in development (2.x). Furthermore there is a good reason for limiting the schema introspection to a certain layer. If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database. This behaviour would even cause a lot more annoyance to users as it is the default use case that users are only interested in one database per entity manager.
Also this problem is completely independant from your mapping definitions. So it doesn't matter whether you prefix your table names or not. When running the "update" operation on the schema tool, it is the online schema introspection part that is preventing the schema tool from behaving as you would wish.
Changing the schema introspection behaviour in DBAL would completely break BC and is at some places in the code not even possible without changing the API.
I am sorry that I have to disappoint you with this conclusion but we I am afraid we cannot do anything about your issue until we start developing 3.x. We might reevaluate your use case their and see what we can do.

Comment by Pavlo Chipak [ 28/May/15 ]

Steve Müller I'm using Symfony2 and tying to do such things on MySQL (one entity manager, one user and multiple databases). I wrote my own realisation of schema:update based on code of original command. I have config parameter with list of schemas (databases) and then inside a command in the loop I reloading EM with selected database. Then, as usual, I'm getting diff of schema. At the end, a have diff (list of queries) for each database and can run it all at one. I know it's bad solution, but may be it can be done something similar and more elegant in the core? Like create white list of schemas parameter for EM. If thats can be done, there will not be a problem like:

If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database.

At next, if in EM config are set more then one schema we always need use schema.table for tabe naming in the Comparator and other core module, and in generated queries. As profit, it must be not hard to allow using cross-database FK.





[DBAL-803] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Bug Priority: Major
Reporter: Stefano Kowalke Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: mysql, querybuilder,
Environment:

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
duplicates DBAL-804 [GH-523] SQLSTATE[HY093]: Invalid par... Resolved

 Description   

This can be closed. I moved the description to http://www.doctrine-project.org/jira/browse/DBAL-804






[DBAL-802] Tablename quoting not working for ALTER TABLE Created: 06/Feb/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Dennis Birkholz Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: Quoting, TableDiff, mysql

Issue Links:
Duplicate
duplicates DBAL-555 Table name is not quoted despite bein... Resolved

 Description   

I use the orm:schema-tool:update to update the database schema of my model which contains a table with the name "Character".
Quoting for this table name works without the need to add backticks in foreign key definitions (references `Character`) but "ALTER Character" misses the quotes.
The reason is that the getAlterTableSQL method of the MySqlPlatform class uses the name property of the supplied TableDiff which does not contain a quoted name.
The original Table information that contained the quoting information is not available from the TableDiff.

A quick fix is to just force a name quoting with "$this->quoteIdentifier($diff->name)" in the getAlterTableSQL but this does ignore all quoting-decision-functionality of doctrine.



 Comments   
Comment by Dennis Birkholz [ 06/Feb/14 ]

Just checked on v2.4.2: the issue is still present there but the TableDiff now contains the original table information object so the fix may be a lot less hacky.

Comment by Steve Müller [ 06/Feb/14 ]

Dennis Birkholz This issue should have been fixed in 2.5, commit: https://github.com/doctrine/dbal/commit/75d35f5809095b37cb7085a9289eca4aa9c6df68
See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L600

Please check again with the current master.

Comment by Steve Müller [ 24/Apr/14 ]

Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-555





[DBAL-761] Driver\ResultStatement::fetchAll() returns empty array on a seemingly valid Driver\PDOStatement object Created: 03/Jan/14  Updated: 08/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Dennis Matveyev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, query, schematool
Environment:

Windows 7 64 bit, Zend Server/Studio, PHP 5.4.16,
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8x



 Description   

I came across a weird issue, where when running:

vendor/bin/doctrine-module orm:schema-tool:update

I would get:

[Doctrine\DBAL\Schema\SchemaException]
There is no column with name 'resource_id' on table 'role_resource'.

But I did have a column with the above name in the above table, so that was a weird message for me. So I traced it all the way to this line of code:

https://github.com/doctrine/dbal/blob/2.4/lib/Doctrine/DBAL/Connection.php#L630

If I remove "->fetchAll()" from that line, I get this object:

object(Doctrine\DBAL\Driver\PDOStatement)#531 (1)

{ ["queryString"]=> string(332) "SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS `Null`, COLUMN_KEY AS `Key`, COLUMN_DEFAULT AS `Default`, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS CollactionName FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'loginauth' AND TABLE_NAME = 'role_resource'" }

Which has a valid SQL query that runs fine and shows Field names on my local machine's MySQL prompt. But when I add ->fetchAll() back in that line of code, an empty array is returned, field names are not returned, and a SchemaException is generated. I found this odd and wanted to report it. Whether it is a bug or not, hopefully I can find the cause of this issue.

For loads more info, please see this: http://stackoverflow.com/questions/20907491/doctrine-2-there-is-no-column-with-name-columnname-on-table-table



 Comments   
Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev It seems you are using MySQL. Can you please tell which version you use?

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Please also provide whether you use mysqli or PDO_MYSQL.

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Sounds dumb, but also are you sure that the vendor/bin/doctrine-module orm:schema-tool:update uses the correct connection parameters and does not by error connect to another database server or something? Because otherwise everything looks good IMO.

Comment by Dennis Matveyev [ 07/Jan/14 ]

Yes, I am using:
Server version: 5.5.23-log MySQL Community Server (GPL)
mysql client Ver 14.14 Distrib 5.5.23, for Win32 (x86)

Doctrine connection string for 'driverClass' is 'Doctrine\DBAL\Driver\PDOMySql\Driver', so it is PDO_MYSQL.

I am connecting to the right database, but your last suggestion is what helped to uncover the issue. When connecting to the database with the very same user/pass, and running the command, here is what I saw:

mysql> select resource_id from role_resource;
ERROR 1142 (42000): SELECT command denied to user 'login'@'localhost' for table 'role_resource'

Running a GRANT command to allow SELECT for this user solved the problem.

To improve debugging of similar issues, I'd see if there is a way to propagate the error from MySQL server to ./doctrine-module,
or
improve the error message of SchemaException, to i.e. "There is no column with name 'action_id' on table 'role_action', or database permissions prevent table access."

Thanks!

Comment by Steve Müller [ 07/Jan/14 ]

Dennis Matveyev Thank you for reporting this and I'm glad I could help. I will mark this as improvement, though. You are right in that the root cause of the error should be propagated to the user instead.

Comment by Steve Müller [ 08/Jan/14 ]

Dennis Matveyev Okay I found the root cause of the problem. See what MySQL states about access to the information_schema table for retrieving metadata about a certain database:

Each MySQL user has the right to access these tables, but can see only the rows in the tables that correspond to objects for which the user has the proper access privileges. In some cases (for example, the ROUTINE_DEFINITION column in the INFORMATION_SCHEMA.ROUTINES table), users who have insufficient privileges will see NULL.

So it returns NULL instead of raising an error and this is why Doctrine is not able to propagate the proper exception in this case. I'm not sure if changing the exception message in the SchemaException class is the proper way of handling this. Also please note that this is not only about columns (where you got stuck at) but can occurr for almost every list*() action called in the SchemaManager I suppose. Furthermore this might be a MySQL specific issue, not sure about that.

The proper solution would be to throw an exception much earlier, to have a decent behaviour in such an edge case. I think we should throw an exception here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L267 because a table cannot live without columns and indicates an error somewhere. But I would like to hear the opinion of Benjamin Eberlei on that issue.

Comment by Steve Müller [ 08/Jan/14 ]

I checked the SQL Server documentation and it seems they behave exactly the same: http://technet.microsoft.com/en-us/library/ms187113.aspx

In SQL Server 2005 and later, the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission. For example, the following query returns a row if the user has been granted a permission such as SELECT or INSERT on the table myTable.

However, if the user does not have any permission on myTable, the query returns an empty result set.





[DBAL-477] Just doublequote all schema names and field names in PostgreSQL sql command generation, and the same for MySQL Created: 28/Mar/13  Updated: 24/Dec/13

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, postgresql
Environment:

Any PostgreSQL environment


Issue Links:
Reference
is referenced by DBAL-96 Make approach towards identifier quot... Open

 Description   

Generation of any SQL command to the database (From entities or migration versions) does not quote all the reserved keywords (For example a fieldname `right`.

Simple fix that always works: double-quote dbname, schemaname and fieldname

e.g "dbsecurity"."userschema"."users" or "tblusers"

MySQL : use the ` sign.

e.g `security`.`users` or `tblusers` (No support for schemas since I last checked some time ago)



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

If those are reserved keywords, they should be added to the "PostgreSQLKeywords" class and they will be quoted by Doctrine. As far as I can see those keywords mentioned are not present in this class. Maybe there is something missing?





[DBAL-442] Break the query building with multiple from parts Created: 10/Feb/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

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

Type: Bug Priority: Major
Reporter: Denis Vasilev Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql


 Description   

For example:

$queryBuilder
    ->select('DISTINCT c.id')
    ->from('Campaigns', 'c')
    ->leftJoin('c', 'CampaignOperations', 'od', 'od.campaignId = c.id AND od.operation = :operation')
    ->from('BannerGroups', 'bg')
    ->innerJoin('bg', 'BannerGroupStrategies', 'bgs', 'bgs.groupId = bg.id AND bgs.advSystem = :system')
    ->where('bg.campaignId = c.id');

Builded the query:

SELECT DISTINCT c.id FROM Campaigns s 
  LEFT JOIN CampaignOperations od ON (od.campaignId = c.id AND od.operation = :operation)
  INNER JOIN BannerGroupStrategies bgs ON (bgs.groupId = bg.id AND bgs.advSystem = :system), 
  BannerGroups bg
  WHERE (bg.campaignId = c.id)

If this query execute on mysql, we get error:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'bg.id' in 'on clause'

Expected result:

SELECT DISTINCT c.id FROM Campaigns s 
  LEFT JOIN CampaignOperations od ON (od.campaignId = c.id AND od.operation = :operation),
  BannerGroups bg
  INNER JOIN BannerGroupStrategies bgs ON (bgs.groupId = bg.id AND bgs.advSystem = :system)
  WHERE (bg.campaignId = c.id)

Regression after patch https://github.com/doctrine/dbal/pull/175



 Comments   
Comment by Denis Vasilev [ 10/Feb/13 ]

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

Comment by Fabio B. Silva [ 22/Apr/13 ]

Fixed by : https://github.com/doctrine/dbal/commit/99574240f332a814ec193b6e7a88abb6a457f061





[DBAL-398] Native query does not allow mysql assignment operator := Created: 18/Dec/12  Updated: 03/Jan/13  Resolved: 22/Dec/12

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

Type: Bug Priority: Major
Reporter: David Ward Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql
Environment:

Using Doctrine within Symfony 2.1.x


Attachments: Text File FixNativeAssignmentOperator.patch    

 Description   

When trying to use the mysql assignment operator in a native query one gets an exception as SqlParserUtils does not qualify the character after the : as being part of a valid parameter value.

Undefined index: in vendor/doctrine/dbal/lib/Doctrine/DBAL/SQLParserUtils.php line 156 (uncaught exception)

A simple example is
$rsm = new ResultSetMapping();
$rsm->addScalarResult('rank', 'rank');
$qry = $em->createNativeQuery("
SELECT (@rank := 1) AS rank
");
$result = $qry->getResult(Query::HYDRATE_ARRAY);

Or a more complicated example is (similar to actual use):

$rsm = new ResultSetMapping();
$rsm->addScalarResult('rank', 'rank');
$qry = $em->createNativeQuery("
SELECT rank FROM
(SELECT (@rank := @rank +1) AS rank FROM (SELECT @rank :=0) rnk2) rnk1
");
$result = $qry->getResult(Query::HYDRATE_ARRAY);

I have attached quick-fix patch, but it looks like the getPlaceholderPositions method is wanting something better overall (due to the TODO comment in it).



 Comments   
Comment by David Ward [ 18/Dec/12 ]

A pull request has been added at https://github.com/doctrine/dbal/pull/237 which also has tests added.

Comment by Bryson Armstrong [ 03/Jan/13 ]

I ran into this error and the fix caused other queries to have errors.

I fixed it by changing line 57 in vendor/doctrine/dbal/lib/Doctrine/DBAL/SQLParserUtils.php:

 
if ($statement[$i] == $match && !$inLiteral && (!$isPositional && $statement[$i+1] != '=')) {

to:

if ($statement[$i] == $match && !$inLiteral && ($isPositional || $statement[$i+1] != '=')) {




Generated at Fri Jul 03 12:27:23 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.