SchemaManager should first look into comment instead of infer the type first.

Steve Tauber added a comment - 14/May/13 8:50 PM This also applies for a type of yaml. Example: /** @Column(type="yaml") */ protected $data = array(); ./scripts/doctrine orm:schema-tool:update --dump-sql ALTER TABLE meta CHANGE data data LONGTEXT NOT NULL; Very frustrating.... Might be related to http://www.doctrine-project.org/jira/browse/DBAL-42

Guilherme Blanco added a comment - 29/Aug/12 8:05 PM This issue is strictly correlated to the commit I've done here: https://github.com/doctrine/dbal/commit/e25c774dde971dc4afd40648e9ccd0af53b34ce9 Mainly, we may have legacy database that we do know how Doctrine should operate. Under this circumstance, we may want to add a comment to the field defining the Doctrine DBAL type. Even though after doing this, Doctrine still complains (in my situation, a SET column type) that it's unable to handle this column type. That happens because MySQL Schema Manager (and others) first looks for the column type: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L112 https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L312 which automatically fails. But if we first try to look for the commented data type: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L884 And forget about the rest if it finds one definition there, it would allow even unknown data types to be managed instead of forcing to define the DBAL Type compatible.

Benjamin Eberlei added a comment - 29/Aug/12 9:39 AM Why is this a bug? Can you say some more about why we need to do this and what error occurs?