MySQL Bugs: #48962: Sync decides to drop all and start fresh

Bug #48962	Sync decides to drop all and start fresh
Submitted:	21 Nov 2009 21:45	Modified:	20 Jul 2012 6:52
Reporter:	Aaron Wallis	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	5.2.8	OS:	MacOS (10.6.2)
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	model, schema, sync

Description:
I have a database which I built using other tools including earlier versions of MySQL Workbench.
After manually re-creating the model in MySQL WB I made some changes (added some new tables) and prepared the db for a schema sync (manually produced a backup).

Prior to using the sync feature in WB I produced a "Catalogue diff report" which presented me with an invalid sync report.
While the schema names and table names match up 100% (including ~99% of the columns, indexes, keys, etc) WB decided that the most effective sync method was to drop all tables and recreate them from scratch.

Obviously a but, I attempted to see what the "Synchronise Model" process would output.
Once the wizard had collected all the information it required, it presented me with this report: http://emberapp.com/d2kagw/images/mysqlworkbench
As you can see, WB was unable to match the two schemas, even though they have the same name (and as mentioned earlier, a similar structure)

Since the sync was not presenting an accurate migration path, I did not proceed to run the sync.

How to repeat:
Whenever I manually design a model (instead of using the reverse engineer feature) and attempt a sync, it simply drops the tables and creates new ones.

Suggested fix:
It's a fairly obvious suggestion, but if there's a merge conflict that can't be automagically acted upon, the user should try and point out the similarities (i.e. train) to assist the sync.

Hi Aaron,

in a case like this, where you have an existing database, you're supposed to rev-engineer the existing database using WBs reverse engineering feature. this should make WB aware that this is an already existing schema (there's quite a bunch of data which is set in the background of the model which enables the synchronization to work correctly and this information is not present in case you're creating the model from scratch).
We will check if we can also make it work for the approach you've been using, when re-creating a existing database from scratch in WB and later try to synch changes to an existing schema on a DB server.

This has been fixed as of the soon-to-be-released Workbench 5.2.41, and 
here's the changelog entry:

The Synchronization wizard has been changed to allow forcing 
synchronization of schemas that have the same name but an unexpected
"last known name", which would cause a confusing scenario of the target
database being recreated from scratch.