Below is the list of changes that have just been committed into a local
mysqldoc repository of root. When root does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2727 05/05/30 15:20:09 Mike.Hillyer@stripped +1 -0
Work in progress commit of MT docs to get them into new MT docs location.
migration-toolkit/migration-toolkit.xml
1.9 05/05/30 15:20:08 Mike.Hillyer@stripped +180 -0
Work in progress commit of MT docs to get them into new MT docs location.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: Mike.Hillyer
# Host: www.openwin.org
# Root: /home/mysqldoc/mysqldoc2
--- 1.8/migration-toolkit/migration-toolkit.xml 2005-05-30 09:05:13 -06:00
+++ 1.9/migration-toolkit/migration-toolkit.xml 2005-05-30 15:20:08 -06:00
@@ -1111,6 +1111,186 @@
<!-- END IN-DEPTH -->
+ <chapter id="mysql-migration-toolkit-extending">
+
+ <title>Extending The &migration_toolkit;</title>
+
+ <sect1 id="mysql-migration-toolkit-extending-introduction">
+
+ <title>Introduction</title>
+
+ <para>
+ One of the key features of the &migration_toolkit; is that it can be
+ easily extended to support new data sources. Through the use of its
+ Generic RunTime Environment (<literal>GRT</literal>), the
+ &migration_toolkit; can support new features and data sources using
+ code written in languages such as Java, PHP, and C.
+ </para>
+
+ <para>
+ Extending the &migration_toolkit; to support a new RDBMS requires
+ the creation of two new modules: one module that reverse engineers
+ (ie., retrieves schema information) the source database objects and
+ converts them into GRT objects, and one module that migrates the
+ source GRT objects into MySQL GRT objects. The &migration_toolkit;
+ then converts the GRT MySQL objects into SQL statements that create
+ the the target MySQL server objects.
+ </para>
+
+ </sect1>
+
+<!-- END INTRODUCTION -->
+
+ <sect1 id="mysql-migration-toolkit-extending-architecture">
+
+ <title>Architecture of the &migration_toolkit;</title>
+
+ <para>
+ The &migration_toolkit; is written on top of the Generic Runtime
+ Environment (GRT): a thin C layer, inspired by Objective C, which
+ allows for dynamic typing and dynamic data objects. The GRT supports
+ the creation of new modules written in C, Java, PHP, and Lua.
+ </para>
+
+ <para>
+ The &migration_toolkit; is built on three primary modules: reverse
+ engineer modules, migration modules, and transformation modules.
+ </para>
+
+ <para>
+ Reverse engineering modules retreive the schema information from the
+ source database and return GRT objects that describe the schema.
+ Reverse engineering modules will have a name similar to
+ <literal>ReverseEngineeringAccess</literal>.
+ </para>
+
+ <para>
+ Migration modules convert the source database GRT objects to MySQL
+ GRT objects and then handle the bulk data transfer between the
+ source and MySQL databases. Migration modules will have a name
+ similar to <literal>MigrationAccess</literal>.
+ </para>
+
+ <para>
+ Transformation modules convert the MySQL GRT objects into the actual
+ SQL statements used to create and load data into the target MySQL
+ server. Transformation modules will have a name similar to
+ <literal>TransformationMySQL</literal>. Transformation modules are
+ supplied by the MySQL GUI team and need not be created to add
+ support for a new source database.
+ </para>
+
+ <para>
+ Reverse engineering and migration modules are derived from base
+ classes whose methods can be re-written to match the new source
+ database.
+ </para>
+
+ </sect1>
+
+<!-- END ARCHITECTURE -->
+
+ <sect1 id="mysql-migration-toolkit-extending-process">
+
+ <title>The Modular Migration Process</title>
+
+ <para>
+ From a module developer point of view, the migration process is as
+ follows:
+ </para>
+
+ <orderedlist>
+
+ <listitem><para>
+ The &migration_toolkit; prompts the user for a source database and
+ connection parameters. The user selection determines which moldules
+ will be used for the source database.
+ </para></listitem>
+
+ <listitem><para>
+ The &migration_toolkit; calls the <literal>testConnection</literal>
+ method of the reverse engineering module. The
+ <literal>testConnection</literal> method returns success or failure
+ to the &migration_toolkit;.
+ </para></listitem>
+
+ <listitem><para>
+ The &migration_toolkit; calls the <literal>getSchemata</literal>
+ method of the reverse engineering module. The
+ <literal>getSchemata</literal> method returns a list of the schemas
+ available on the source RDBMS for the user to choose from.
+ </para></listitem>
+
+ <listitem><para>
+ Once the user has selected a schema to migrate, the
+ &migration_toolkit; calls the <literal>reverseEngineer</literal>
+ method of the reverse engineering module. The
+ <literal>reverseEngineer</literal> method converts all objects in
+ the source RDBMS (tables, views, procedures) into a collection of
+ GRT objects.
+ </para></listitem>
+
+ <listitem><para>
+ After the source database has been reverse engineered, the
+ &migration_toolkit; calls the <literal>migrationMethods</literal>
+ method of the migration module. The
+ <literal>migrationMethods</literal> method generates a list of
+ available methods than can be selected by the user in the
+ <link linkend="mysql-migration-toolkit-indepth-mapping">Object
+ Mapping Screen</link>.
+ </para></listitem>
+
+ <listitem><para>
+ Once the user has selected the migration methods, the
+ &migration_toolkit; calls the <literal>migrate</literal> method of
+ the migration module. The <literal>migrate</literal> method
+ converts the source RDBMS GRT objects into MySQL GRT objects.
+ </para></listitem>
+
+ <listitem><para>
+ After the MySQL GRT objects have been created, the
+ &migration_toolkit; calls the transformation moldule to convert the
+ MySQL GRT objects into SQL statements that will create the objects
+ on the target MySQL server. The &migration_toolkit; then either
+ executes the SQL statements on the target MySQL server or writes
+ them to a script file.
+ </para></listitem>
+
+ <listitem><para>
+ In the final step, the &migration_toolkit; calls the
+ <literal>dataBulkTransfer</literal> method of the migration module.
+ The <literal>dataBulkTransfer</literal> method loops through the
+ selected tables in the selected schema and migrates the rows of the
+ tables to the target MySQL database or loads them into a script
+ file, depending on the user preference.
+ </para></listitem>
+
+ </orderedlist>
+
+ </sect1>
+
+<!-- END PROCESS -->
+
+ <sect1 id="mysql-migration-toolkit-tools">
+
+ <title>Tools Required to Extend the &migration_toolkit;</title>
+
+ <para>
+ The MySQL AB GUI Team uses Eclipse for development of the
+ &migration_toolkit; modules and recommends Elcipse for use when
+ developing modules for the &migration_toolkit;. See
+ <ulink url="http://www.eclipse.org/">http://www.eclipse.org/</ulink>
+ for more information.
+ </para>
+
+ </sect1>
+
+<!-- END TOOLS -->
+
+ </chapter>
+
+<!-- END EXTENDING CHAPTER -->
+
<appendix id="mysql-migration-toolkit-accessprep">
<title>Preparing a Microsoft Access Database for Migration</title>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (Mike.Hillyer:1.2727) | mhillyer | 31 May |
