Bug #33279 crash when dragging into EER diag due to bad foreign key defs in imported sql
Submitted: 17 Dec 2007 1:51 Modified: 17 Dec 2007 19:09
Reporter: Ian Katz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S1 (Critical)
Version:5.0.10 OS:Windows (XP SP2)
Assigned to: Sergei Tkachenko CPU Architecture:Any

[17 Dec 2007 1:51] Ian Katz
Description:
mysql workbench crashes when i drag a table from the catalog into an EER diagram.   this only happens for tables created by the "file -> import -> reverse engineer mysql create script", when part of the primary key is also a foreign key and the foreign key reference is improperly defined (sample sql below).  

any of the tables in the schema will cause the crash when dragging into the diagram, not just the one with the bad reference.  

How to repeat:
1. save this SQL 
crash.sql <<< ENDofSQL

create table dog (
    dog_id int unsigned not null auto_increment,

    primary key (dog_id)
    );

create table trick (
    trick_id int unsigned not null auto_increment,

    primary key (trick_id)
    );

create table dog_trick (
    dog_id int unsigned not null,
    trick_id int unsigned not null,

    primary key (dog_id, trick_id),
    foreign key (dog_id) references dog (SOME_NONEXISTENT_FIELD),
    foreign key (trick_id) references trick (trick_id)
    );

ENDofSQL

2. import using file -> import -> reverse engineer (crash.sql).

3. create a new EER diagram

4. drag any of the tables from the catalog into the diagram.

5. crashes.

(interestingly, if you fix the reference to dog_id and break the reference to trick_id, there is no crash)

Suggested fix:
at the very least, validate imported sql on load and provide warnings at that point.  

reason: (you can skip this if you want, its just backstory)
the first time i encountered this bug, i had done a lot of work between importing the .sql file and making the EER diagram.  i thought the problem was related to one of the tables i had entered manually!  after all, the tables still appeared in the catalog -- even though they had errors.  since i use mysql workbench to visualize and improve my database design, it would make sense for the program to inform me about problems like this.
[17 Dec 2007 9:34] MySQL Verification Team
Thank you for the bug report.
[17 Dec 2007 19:09] Sergei Tkachenko
Thank you for your bug report. Special thanks for tracking down & narrowing the problem. This issue has been committed to our source repository of that product and will be incorporated into the next release.

Implemented solution is to remove improper foreign key & add appropriate warning message to log during reverse engineering.