MySQL Bugs: #62596: Some of the exposed scripting methods in DbMySQLImpl are improperly restricted

Bug #62596	Some of the exposed scripting methods in DbMySQLImpl are improperly restricted
Submitted:	2 Oct 2011 0:00	Modified:	10 Aug 2012 6:11
Reporter:	John Robinson	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S3 (Non-critical)
Version:	5.2.34	OS:	Any
Assigned to:	Alfredo Kojima	CPU Architecture:	Any
Tags:	script scripting sql generation plugin

Description:
Several of the exposed methods in DbMySQL are useless in the way they're exposed and generating full SQL scripts from a script/plugin seems impossible. For example, some functions attempt to modify the dictionaries to return the SQL scripts, but this seems limited by the definitions and in the scripting world, the dictionaries never get updated. The definitions define them as const, and they reference objects using qualified names.

some methods like makeSQLExportScript seem to be improperly exported in the code.

scripting shell lists it as this:
makeSQLExportScript(GrtNamedObject, dict, dict, dict)

in the C++ header its defined as this:
-------------------------
  virtual int makeSQLExportScript(GrtNamedObjectRef,
                                  const grt::DictRef& options,
                                  const grt::DictRef& createSQL,
                                  const grt::DictRef& dropSQL);
-------------------------

In this case, it attempts to modify the input options dictionary

from DbMySQLImpl::makeSQLExportScript
-------------------------

   std::string sql= get_export_sql(catalog, options, createSQL, dropSQL, get_grt());
 
   // final script is output in options dict
   ((grt::DictRef)options).set("OutputScript", grt::StringRef(sql));
-------------------------

also, several of the functions use qualified names to store objects in dictionaries but I can't find these names publicly available to use from a script so they must be generated by hand using something like this:

-------------------------
d2 = dict([( '{0}::`{1}`.`{2}`::{3}'.format( table.__grtclassname__, schema.oldName, table.oldName, table.name ).upper() ,table.name) for table in schema.tables]) 
-------------------------

How to repeat:
import grt
from grt.modules import DbMySQL
import string

schema = grt.root.wb.doc.physicalModels[0].catalog.schemata[0]
  
d1 = {'GenerateDrops': 1, 'GenerateUse': 1, 'GenerateWarnings': 1, 'GenerateSchemaDrops': 1, 'GenerateCreateIndex' : 1}
d2 = dict([( '{0}::`{1}`.`{2}`::{3}'.format( table.__grtclassname__, schema.oldName, table.oldName, table.name ).upper() ,table.name) for table in schema.tables]) 
d3 = dict()
print DbMySQL.makeSQLExportScript(grt.root.wb.doc.physicalModels[0].catalog, d1, d2, d3)

print(d1)

Suggested fix:
1. expose / correct the qualified name issue with the dictionaries
2. change function return types to be strings or remove the const keyword from dictionaries that are expected to be modified

the supplied script to reproduce, the d1 dictionary should have an additional item that contains the output, named "OutputScript"

also, the qualified name code is in    modules/db.mysql/src/module_db_mysql_shared_code.h

and the specific functions are:

    get_full_object_name_for_key

and possible some of the others in there for other areas.

The reverse and forward engineering modules will be reviewed.

In 5.2.41 new DbMySQLRE and DbMySQLFE modules were added. They have a friendlier and more sensible public API.
You can look at the migration module for sample usage.

Also, the constness in arguments from the C++ interface is not relevant to how the functions are used from the exposed Python interface.

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

Several exposed "DbMySQL" methods (such as "makeSQLExportScript") were
problematic, and have been replaced by the "DbMySQLRE" and "DbMySQLFE" modules.