DBAL-276: MySQL schema manager should not make assumptions about non-DBAL types #1455

Closed
doctrinebot opened this Issue May 16, 2012 · 2 comments

2 participants

@doctrinebot

Jira issue originally created by user predakanga:

When using the DBAL MySQL schema manager to create migrations or update the schema directly, it can create conflicts with custom types due to the way it processes some non-DBAL types in _getPortableTableColumnDefinition.

I recently implemented a binary-string type, using the MySQL BINARY/VARBINARY columns (as opposed to blob, which I see has been adopted in 2.2), due to the content for my application always being a 60 byte binary string. Doctrine has been working fine with it, but upon generating my next migration, I discovered that the schema manager wanted to re-set the column's length.
Generated SQL: "ALTER TABLE User CHANGE password password VARBINARY(60) NOT NULL"

It appears that this is caused by lines 138 & 139 of MySqlSchemaManager.php clearing the column's length. There doesn't seem to be any other code pertaining to MySQL and binary/varbinary, so removing these two lines should be safe and save trouble for future users, without causing issues for those who choose to implement it as a blob or similar.

@doctrinebot

Comment created by @beberlei:

Fixed

@doctrinebot

Issue was closed with resolution "Fixed"

@doctrinebot doctrinebot added the Bug label Dec 6, 2015
@beberlei beberlei was assigned by doctrinebot Dec 6, 2015
@doctrinebot doctrinebot added this to the 2.1.7 milestone Dec 6, 2015
@doctrinebot doctrinebot closed this Dec 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment