Fixed changeColumn varchar adds 'unsigned' to query

[Lukas W.]

Affected version

2.1.3

$table->changeColumn('length', 'varchar', 10)->setDefault(0);

converts to

MODIFY COLUMN `length` VARCHAR(10) UNSIGNED DEFAULT '0'

which throws an error on UNSIGNED. Adding ->unsigned(false) to the statement above resolves the issue.

 

[Chris D]

It doesn't "add" it as such. It's already there. Presumably you're changing a INT column which already has UNSIGNED to a VARCHAR.

For the most part, when you're changing a column, it attempts to keep as much of the original column config as possible. In addition to setting unsigned to false, the other workaround is to call ->resetDefinition() on it.

That said, I agree it would be illogical for a varchar column to keep the unsigned property so we'll try and address that. But, just be aware that sometimes when changing a column, you'll need to reset its definition or manually adjust the existing properties of it.

 

[XF Bug Bot]

Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.4).

Change log:

When using the schema manager and changing an existing column to a non-int type, remove the unsigned property if set.

Any changes made as a result of this issue being resolved may not be rolled out here until later.