Bug #68369 Synchronize model fails for columns with DEFAULT NULL
Submitted: 13 Feb 2013 17:39 Modified: 20 Jun 2013 20:10
Reporter: Rasmus Schultz Email Updates:
Status: Closed Impact on me:
Category:MySQL Workbench: Modeling Severity:S2 (Serious)
Version:6.0.2 beta OS:Microsoft Windows (Windows 8)
Assigned to: CPU Architecture:Any
Triage: Needs Triage: D2 (Serious)

[13 Feb 2013 17:39] Rasmus Schultz
When synchronizing any model with columns with a default value of NULL, these columns appear to MWB to have changed, every time.

I'm using MySQL 5.5.27 under Windows 8.

I'm reporting this as S2 (Serious) since this makes the synchronization feature unusable.

How to repeat:
Download this sample project:


To repeat the problem, first create the database for forward engineering.

Then attempt to synchronize the model - you would expect to see nothing has changed, but instead you get an ALTER TABLE statement like this:

    ALTER TABLE `test`.`users` CHANGE COLUMN `address` `address` VARCHAR(45) NULL DEFAULT NULL  

Running a catalog diff report results in the following:

    Table `test`.`users` was modified
      - modified column address

On a related note, perhaps it would be a good idea to enhance the catalog diff report to actually explain what change MWB thinks it has detected - this would enable us to provide better bug reports for synchronization issues in the future.
[13 Feb 2013 22:59] Miguel Solorzano
Thank you for the bug report.
[3 Jun 2013 15:33] Alfredo Kojima
This synchronization bug was fixed in the repository
[12 Jun 2013 0:22] Philip Olson
Fixed as of the upcoming MySQL Workbench 6.0.2 release, and here's the changelog entry:

When synchronizing a model with columns with default values of "NULL",
MySQL Workbench would always treat these columns as having changed.

Thank you for the bug report.
[18 Jun 2013 13:38] Rasmus Schultz
I've attached a project (privately) that demonstrates some minor issues remaining with synchronization:

Views apparently now always register as changed (since 6.x, see `expected_arrival`)

One table appears as changed but the list of changes in the dialog is empty (same as 5.x, see `collaboration`)

And CHAR(*) ASCII columns still register as changed every time (same as 5.x, see `person`)

Hope this is helpful - I think we're very close to working synchronization now! Results are much better than previously with the 5.x release.

Thank you for all your hard work on this! The beta release is already a milestone closer to being the perfect modeling tool for MySQL! :-)
[18 Jun 2013 13:55] Rasmus Schultz
Looks like you also introduced a new bug in the Forward Engineer function - the "generate INSERT statements for tables" option no longer works; no INSERT statements are generated since the 6.0.2 beta release.
[20 Jun 2013 19:54] Alfredo Kojima
Rasmus, thank you for checking the bug in 6.0.2. However, please file a separate bug for the new issues you found, as they're different from this one. About the View sync issue, it's a known issue that we're working on and it's already filed as bug #65108 It's problematic because the server modifies the view code.
[20 Jun 2013 20:03] Alfredo Kojima
I can confirm the regression with INSERTs, it has already been fixed in our repository.
[20 Jun 2013 20:10] Rasmus Schultz
Opened #69530, #69531 and #69532