MySQL Bugs: #47766: Naming Rules of foreign keys and "Synchrnoize Model" Problems

Bug #47766	Naming Rules of foreign keys and "Synchrnoize Model" Problems
Submitted:	1 Oct 2009 15:44	Modified:	17 Dec 2009 14:41
Reporter:	Bruno Baketaric	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	5.1.18	OS:	Any
Assigned to:	Alexander Musienko	CPU Architecture:	Any

Description:
Foreign Key Indexes are usually named like:
fk_%stable%_%dtable%
and are automatically suffixed with a "1".

Ok, sounds like a good approach, but:
the "Synchronize Model" Module always drops and recreates those indexes, if the name gets too long, i.e. "fk_comb_mt_models1". 
If I rename the index to "fk1_comb_mt_models", WB doesn't always recreate this index.

Always having to change the FK Index Names to make the Sync Model Module happy is quite annoying.

My Server Version is 5.0.77.

How to repeat:
1) Create 2 (InnoDB?) tables with quite long names.
2) Make any kind of relation between them
3) Sync the Model
4) Sync it again...WB wants to drop an recreate the FOREIGN KEY index: wrong, no changes at all.
5) Rename the index according to my scheme 
6) Sync the Model
7) Sync the Model ... WB want's to do nothing: correct.

Thank you for the bug report. Could you please provide a model file test case?. Thanks in advance.

(Sorry for the delay, I've been on vacation.)
Take a look at the model attached to bug id #47767.

Please, try to repeat with a newer version, 5.1.18, and inform about the results.

I'm already using Version 5.1.18 in the meantime: Same result.

Thank you for the feedback.

Hi, now I'm quite sure this problem doesn't relate to the Naming rules of FK's - (at least not only).
I've some tables in my model with foreign keys and indexes that WB is able to sync correctly. In others, it always wants to recreate the last index shown in the "indexes" Tab of WB.
I haven't found any workaround or was able to find some kind of logical correlation.
It just sometimes works and sometimes not.

this has been fixed in repository.
will be included in 5.2.11

An entry has been added to the 5.2.11 changelog:

When a schema containing tables with foreign key indexes was synchronized with a live server, MySQL Workbench attempted to erroneously drop and recreate at least one of the foreign key indexes.