MySQL Bugs: #52373: User-defined datatype of UNSIGNED INT loses UNSIGNED during Synchronize Model...

Bug #52373	User-defined datatype of UNSIGNED INT loses UNSIGNED during Synchronize Model...
Submitted:	25 Mar 2010 17:25	Modified:	14 Jun 2013 6:05
Reporter:	mike blackman	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S3 (Non-critical)
Version:	5.2.16 beta	OS:	Linux (Ubuntu 9.10)
Assigned to:		CPU Architecture:	Any
Tags:	UNISGNED INT synchronize model user defined data type

Description:
When using the "Synchronize Model..." feature to generate SQL to modify an existing database, the SQL does not include the UNSIGNED, even though the user-defined data-type has the box checked.
The UN box IS checked in the "Columns" tab of the "Edit Table" panel, and the UNSIGNED option appears correctly in the SQL if you either use "Forward Engineer..." the model, or even right-click the table and choose "Copy SQL to clipboard".

Also note that "Synchronize Model..." does not seem to modify columns and switch them from INT(11) to INT(11) UNSIGNED, too.

How to repeat:
1) Start with an existing schema with some # of tables.
2) Create a user-defined data-type.  I called mine UINT, and it is INT(11) with the UNSIGNED box checked.
3) Create a NEW table in the modeler, and create a primary auto-increment column, and choose UINT as the data-type.  Note that the UN box for that column appears selected.
4) Use the "Forward Engineer..." option, going only as far as previewing the SQL to be generated.  Note that the CREATE TABLE statement includes the UNSIGNED option for the column.
5) Close that dialog without actually applying the SQL, and use the "Synchronize Model..." option to generate a CREATE statement for the table.
6) Note that in the SQL preview, the UNSIGNED option is NOT included for the column.

Suggested fix:
Include the UNSIGNED option in the SQL for CREATE TABLE during the "Synchronize Model..." feature.

Many thanks for writing a bug report.

Verified as described.

I have the same issue on Windows XP with a user defined type of BIGINT(16) UNSIGNED, using version 5.2.25 of the Workbench.

Interestingly not all tables using the type are affected during the Synchronize.

I fiddled around with my model to try and discover what caused some tables to have the issue and others not to. I gave up after a while because one table just refused to show the issue.

I have attached my model to the Bug.

To reporduce:
1) Open my model
2) Forward engineer the model
3) Synchronize the model
4)Review the synchronize script. Notice how tables TargetIMSIs and TargetIMIEs are affected but Sessions is not.

Same bug present on MacOS version as well.  Version 5.2.31.

still loses unsigned on sync, but not forward engineer in version 5.2.44

This bug is also there when syncing an existing table :
- the column is shown as different than the one from the server
- and, therefore, an ALTER TABLE command is issued without the UNSIGNED

Very annoying, because that worked before. From my point of view, it's exactly as if the SYNC function didn't work at all anymore (all my tables are marked "modified", I have to check them one by one to ignore them)

Fixed as of the upcoming MySQL Workbench 6.0.2 public beta release, and here's the changelog entry:

When "Synchronize Model" the feature was used to generate SQL to modify an
existing database, it would lose the UNSIGNED attribute while executing
the synchronization.

Thank you for the bug report.