MySQL Bugs: #40914: Synch problem - recognition model changes and saving

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:	Windows (XP SP3)
Assigned to:	Alexander Musienko	CPU Architecture:	Any
Tags:	changes, CHECKED, Saving, synchronization

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

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

Table sync issues fixed, but there is still view and procedure remained forever wants to sync.

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).

fixed in repository of 5.1

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.