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:Microsoft Windows (7Ux64)
Assigned to: CPU Architecture:Any
Tags: rename, schema, synchronisation
Triage: Needs Triage: D3 (Medium)

[18 May 2011 6:54] Maxime MARAIS
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.
[18 May 2011 7:02] Valeriy Kravchuk
Thank you for the problem report and detailed workaround description.
[18 May 2011 12:49] Alfredo Kojima
marked bug #61157 as duplicate
[18 May 2011 12:50] Alfredo Kojima
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"
[20 Jun 2011 15:35] Rok Dominko
@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?
[20 Jun 2011 16:10] Alfredo Kojima
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.
[22 Feb 2012 8:54] Wojciech Mocarski
Hi,

Is there any progress accourding to the issue?

Regards
Wojtek
[28 Mar 2012 9:27] Bogdan Yurov
Please, fix it ASAP. Nearly every week see this bug
[3 May 2012 6:58] Paul Rigney
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
[12 May 2012 19:04] Ted Yates
Any updates on this bug?  Fixed, it would be a well used feature.  First reported June, 2009 #45533.

Thanks for the fantastic app.
[28 Jun 2012 11:03] André Ricardo
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
[4 Jul 2012 12:29] André Ricardo
Paul Rigney's script still works! Thank you Paul!
[27 Jul 2012 8:45] Philip Olson
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.