MySQL Bugs: #36177: Database Synchronize shows inconsistent behaviour

Bug #36177	Database Synchronize shows inconsistent behaviour
Submitted:	17 Apr 2008 11:13	Modified:	11 Jul 2008 9:18
Reporter:	Johannes Taxacher	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	5.0.19 rev 3067	OS:	Windows
Assigned to:	Vladimir Kolesnikov	CPU Architecture:	Any

Description:
I run the wizard and select a destination schema with a different name than the schema in my document on wizard page 3.
Then i get to the SQL diff tree where i see a tree with my document schema mapped to the selected destination schema on server (just as i'd expect).
Now i cancel the action and repeat the exact same steps leading to the sync-wizards diff tree page again - but this time i see two trees, one is my document schema mapped to a N/A (so i guess it will be created on server) and another N/A schema mapped to the selected destination schema on server (so i assume the destination schema will be dropped on server)
the resulting model on server should be about the same - but i loose all my data there

How to repeat:
- open attached model and forward engineer it to a database server (tested with 5.1.22-rc-community)
- rename the schema in document to `my_other_sync_schema` (or whatever)
- use database->synchronize
- select connection, select the "destination" schema `my_sync_schema` on server
- continue to the Diff tree page (should look like attached image 1)
- click next to see the sync-code to be executed on server (sync codes of both steps in attached textfile)
- now click cancel and run DB wizard again using exact same steps
- reaching the diff tree page notice the difference to first try (it looks like attached image 2)
- click next to see the diff code ... this time it drops the existing database and creates it from scratch

test_document for testing synchronization

Attachment: my_sync_schema.mwb (application/x-extension-mwb, text), 3.26 KiB.

diff tree on first sync-run

Attachment: sync_schema_1st_try.png (image/png, text), 14.28 KiB.

diff tree on second sync-run

Attachment: sync_schema_2nd_try.png (image/png, text), 18.46 KiB.

sync-code output for both synchronization tries

Attachment: sync_output.txt (text/plain), 2.04 KiB.

I changed a table name and some indexes in my diagram and experienced a similar problem

As I have a number of layers and the diagram was as I wanted it, I spent some time trying to find a fix for this problem but didn't discover a solution. 

My workaround was to adjust the indexes, in HeidiSQL as I wanted to do in Workbench. 

I deleted the Workbench objects and reverse engineered the database again.

now the sync-changes are posted to the model at the very last step right before executing the code. This way the behaviour is as expected when the wizard is cancelled and re-run.

note: one has to be careful with database renaming as server docs point out that this can lead to dataloss!

this fix will be incorporated in 5.0.23.

An entry has been added to the 5.0.23 changelog:

The behaviour of the Synchronize wizard was inconsistent when cancelled and re-run.