Bug #49063 Workbench does not detect signed/unsigned changes in schema

Submitted: 24 Nov 2009 20:00 Modified: 1 Dec 2009 9:57
Reporter: Giuseppe Maxia Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S2 (Serious)
Version:5.1.18, 5.2.8 OS:MacOS
Assigned to: Alexander Musienko CPU Architecture:Any
Tags: changes, schema, synchronization, UNSIGNED

[24 Nov 2009 20:00] Giuseppe Maxia
Description:
MySQL Workbench does not detect or act adequately when the only change in the schema is a signed/unsigned integer.
For example, your main database has a table with a INT column, and the development database has the same table with INT UNSIGNED. Workbench doesn't report the difference, and produces an ALTER TABLE that is the same (without the UNSIGNED attribute) no matter which database we ask to update.

How to repeat:
1. on server "main", create a table t1 (i int)
2. on server "dev", create a table t1(i int unsigned)
3. reverse engineer database on server "main"
4. synchronize model
5. check the ALTER TABLE generated for both "update model" and "update source"

Suggested fix:
Make WB detect changes of sign.
[26 Nov 2009 17:18] Johannes Taxacher
this also affects live editors. if you only change the unsigned flag of a table you dont get to apply that change ...
[1 Dec 2009 0:50] Johannes Taxacher
fixed in repository. will be included in 5.2.10
[1 Dec 2009 5:43] Giuseppe Maxia
Please fix this problem also in the 5.1.x version
[1 Dec 2009 9:57] Tony Bedford
An entry has been added to the 5.2.10 changelog:

MySQL Workbench did not handle signed and unsigned integers correctly. For example, if performing a synchronization between a model and a live database where the only difference was a column was declared to be of type INTEGER in one case and UNSIGNED INTEGER in the other, the difference would not be detected and the ALTER script would imply the databases were the same.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.042 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.