MySQL Bugs: #61211: Rename database schema makes synchronisation impossible

Bug #61211	Rename database schema makes synchronisation impossible
Submitted:	18 May 2011 6:54	Modified:	27 Jul 2012 8:45
Reporter:	Maxime MARAIS	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S2 (Serious)
Version:	5.2.33 CE	OS:	Windows (7Ux64)
Assigned to:		CPU Architecture:	Any
Tags:	rename, schema, synchronisation

Description:
When changing a Physical Schemata name (and applying to all tables), synchronization to an existing database source with the same name makes the whole database schema to be dropped and recreated from scratch when expected to simply synchronize both model and source.

This scenario may come when you are trying to apply a model to a forked database structure during development phase (multi-user development environment, development and pre-production environment, etc.

See http://forums.mysql.com/read.php?159,420105,420105

How to repeat:
Make a clone of a physical database with a different name (ex. ModelName), rename the Physical Schemata to the same name in MySQL Workbench and and try to synchronize. You will get this screen :

Model      |  Source
--------------------------
ModelName ===> N/A
N/A       ===> ModelName

Workaround (trick) :

1. Close your model in MySQL Workbench 
2. Change your model file extension (.mwb) to .zip 
3. Open the renamed file with your preferred Zip tool (WinZip, 7zip, WinRar...) 
4. Extract document.mwb.xml file (on your desktop for example) 
5. Edit this file and use the "replace all" feature of your preferred editor (Notepad++, UltraEdit, even Notepad) in order to rename the current database schema to its new name. Take care not to change other words in the XML file that would not be linked directly with your model name (ie. a tag property, for example). To prevent this you may add ">" and "<" around you schema name. Example, replace ">oldname<" with ">newname<" 
6. Save the XML file and replace the one existing in the Zip archive with the one you edited. 
7. Save the archive if not done automatically 
8. Change back your archive file extension (.zip) to .mwb 
9. Open the file in MySQL Workbench. 

Suggested fix:
When renaming, ask if rename action may be also applied to physical database or if rename action may only permit target physical database change.

In the first case, keep oldName property to the original Physical Schemata name, else change both name and oldName to new name.

Thank you for the problem report and detailed workaround description.

marked bug #61157 as duplicate

A workaround is to open the Scripting Shell, inspect the name of the schema and make
sure that the oldName field contains the same name as what you're trying to synchronize
against. 
Commands for that are:

# print current oldName value
print grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName
# change the oldName field value
grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName = "newname"

@Alfredo: your "workaround" chrashes my Workbench (version 5.2.34 CE)

This bug is know for more than a year now. Is it too dificult to fix or is there some other reason, why this hasn't been fixed by now?

This bug is more complex than it may look from the surface because there are several special cases 
involves and time is needed to properly come up with an acceptable solution and implement it.
However it is already relatively high on our priority list and it will be eventually be fixed, please be patient.

Hi,

Is there any progress accourding to the issue?

Regards
Wojtek

Please, fix it ASAP. Nearly every week see this bug

If you are using linux I have writen a shell script to replace steps 2-8 of the manual process that Maxime MARAIS wrote.

Just run the script against your save .mwb file (but back it up 1st)

#!/bin/sh
#
# Rename an mwb file in mysql workbench
# usage 
# dbw.sh db.mwb oldschemaname newschemaname
# Author Paul Rigney
unzip $1
cat document.mwb.xml | sed "s/$2/$3/g" > document.mwb.xml.$$
mv document.mwb.xml.$$ document.mwb.xml
zip $3.mwb @db/ document.mwb.xml lock
rm -fr @db  document.mwb.xml  lock

Any updates on this bug?  Fixed, it would be a well used feature.  First reported June, 2009 #45533.

Thanks for the fantastic app.

Hello, can someone post a alternative to:

# print current oldName value
print grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName
# change the oldName field value
grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName = "newname"

I tried it in version 5.2.40
/ > print grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName
luart: error: stdin:1: '=' expected near 'grt'

I tried the "Copy Path for Python" 
grt.root.wb.doc.physicalModels[0].catalog.schemata

print grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName
luart: error: stdin:1: '=' expected near 'grt'
/ > show 
grt.root.wb.doc.physicalModels[0].catalog.schemata
luart: error: stdin:1: object 'grt.root.wb.doc.physicalModels[0].catalog.schemata' not found
/ > show 
print grt.root.wb.doc.physicalModels[0].catalog.schemata
luart: error: stdin:1: object 'print grt.root.wb.doc.physicalModels[0].catalog.schemata' not found

Paul Rigney's script still works! Thank you Paul!

Fixed as of Workbench 5.2.41, and here's the changelog entry:

The synchronization wizard now allows the possibility to force
synchronization of schemas that are thought to have been
renamed. Otherwise, MySQL Workbench will recreate the schema from
scratch.