MySQL Bugs: #36381: Multiple Reverse Engineer operations destroy model diagrams

Bug #36381	Multiple Reverse Engineer operations destroy model diagrams
Submitted:	28 Apr 2008 16:02	Modified:	9 Jul 2008 17:14
Reporter:	Christian Kopp	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:	5.0.21	OS:	Windows
Assigned to:	Sergei Tkachenko	CPU Architecture:	Any

Description:
After reverse engineering a SQL create script and drawing some EER diagrams, a subsequent import of the same script destroys the EER diagrams. All tables in the catalog are updated, but the reference of the table in the diagram to the table in the catalog seems to be lost. The tables in the diagram are still visible, but do not correspond to the table in the catalog. 
After closing and re-opening the file, all diagrams are empty and it is impossible to delete the diagrams. Funny: in the overview in the upper right corner, the tables placed in the diagram are still visible.

How to repeat:
- import a SQL create script
- add a diagram and place some table in the diagram
- import a same SQL create script again
- close the file
- open the file again

Screenshot

Attachment: screenshot.gif (image/gif, text), 41.75 KiB.

SQL create script used for import

Attachment: test.sql (text/plain), 2.76 KiB.

Destroyed MySQL Workbench file

Attachment: test.mwb (application/x-zip-compressed, text), 6.55 KiB.

That's because provided SQL script contains DROP statements. Parser processes DROP and some ALTER statements along with CREATE statements. It's necessary to import SQL dumps, containing CREATE statements for temporary objects.

Later rev-eng will have parameters page, where it will be possible to switch off processing of drop statements.

Current workaround is to remove drop statements from SQL script if you don't wan't to overwrite existing catalog objects.

Hi Sergei,

thanks for your quick response and the workaround.

Regards,

Christian

The following solution was applied to fix this bug: "drop" statement from now on deletes all model figures attached to the object being dropped.
In version 5.1 additional wizard page with options will be added allowing to disable processing of "drop" statements. But note, in that case "create" statements duplicating existing objects' names will be ignored.
Fix will go in v5.0.23

Now drop commands are fully executed. If you import a sql-script which includes a drop for a table existing in the model, the table is deleted in the model (and all occurences of that table are removed from diagrams).
This fix will go into 5.0.23

An entry was added to the 5.0.23 Changelog:

After reverse engineering a SQL create script and drawing some EER diagrams, a subsequent import of the same script destroys the EER diagrams. All tables in the catalog are updated, but the reference of the table in the diagram to the table in the catalog is lost. The tables in the diagram are still visible, but do not correspond to the table in the catalog. 

After closing and re-opening the file, all diagrams are empty and it is impossible to delete the diagrams. However, in the overview in the upper right corner, the tables placed in the diagram are still visible.