Bug #40914 Synch problem - recognition model changes and saving
Submitted: 21 Nov 2008 6:49 Modified: 8 Feb 2010 15:21
Reporter: Mike Zielinski Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S3 (Non-critical)
Version:5.0.x OS:Microsoft Windows (XP SP3)
Assigned to: Alexander Musienko CPU Architecture:Any
Tags: changes, CHECKED, Saving, synchronization
Triage: Triaged: D3 (Medium) / R3 (Medium) / E3 (Medium)

[21 Nov 2008 6:49] Mike Zielinski
Description:
I save a model, click synchronization and get a message that everything went fine.
After that I click once again synchronization and repeat the process. Then I see that some tables are again synch like they were changed.

In the mean time on the window "SQL Diff Tree" I see that my model becomes unsaved. Before this windows appears model was saved. So after synchronization I have to save the model once again. I have no idea why and what this process is changing in my model.

How to repeat:
I`ll provide .mwb
[21 Nov 2008 10:41] Johannes Taxacher
tracked down two of the problems we have to solve:
- TINTYINT DEFAULT 1 seems to have a faulty comparison to the databases report of TINYINT DEFAULT '1'
- TIMESTAMP NOT NULL (without given DEFAULT val) will be created by server as TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ... and thyts why it differs from model
[5 Dec 2008 14:35] Alexander Musienko
Table sync issues fixed, but there is still view and procedure remained forever wants to sync.
[24 Mar 2009 19:49] Mark Grabowski
I have a similar issue, same platform and edition (5.0.30SE).
Yesterday I started getting all kinds of errors when synchronizing to a windows ( XP PRo in a virtual machine) base version of mysql 5.1.30.
sorry - I did not wite down the information. When doing the the model mysql validation some of the errors claimed that the tables did not exist.

Today I thought about it and since we are still early in the project I dropped the entire schema on the db side. Then I forward engineered the model to the db. Everything went fine. Then immediately, just out of curiosities sake, I did a synchronize, expecting nothing to be different between physical and model.
But severla changes did show up. curiously I applied those and did a synch again. It still thinks they are not in sync ( but some of the differnces are different than before! ( i did not apply these) I use the diff function and it comes up with the same diffs as the synch - at least that is consistent. 

It seems some of the reasons for this are the mismatch between the db and the workbench generating sql.
For example, on the floats there seems to be a keyword difference:
from physical:
`minwarn` float DEFAULT NULL COMMENT 'low value at which warning should be raised.',
from model:
`minwarn` FLOAT NULL COMMENT 'low value at which warning should be raised.' ,

Another one:
db: UNIQUE KEY `as_code` (`assetcode`),
model: UNIQUE INDEX `as_code` (`assetcode` ASC)
( we are enot sure if it is noticing diff on use of ASC or in Key vs Index.)

While this is not a critical issue in terms of execution, it would seem critical in terms of functionality ( after all this is one of the reasons I got the SE version).
[8 Feb 2010 11:43] Johannes Taxacher
fixed in repository of 5.1
[8 Feb 2010 15:21] Tony Bedford
An entry has been added to the 5.1.19 changelog:

Synchronizing a model with a live database, without having made any changes to the model or the database, caused the model to appear as unsaved, indicating that unnecessary changes may have been made to the model.