db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramin Moazeni" <rmoaz...@gmail.com>
Subject Re: MySQL to Derby Migration Tool
Date Thu, 29 Jun 2006 10:25:31 GMT
Hi David,

Thanks for your comments.
My comments inline....


On 6/27/06, David Van Couvering <David.Vancouvering@sun.com> wrote:
> Hi, Ramin.  Great document!  Very nicely done.
> Here are my comments:
> - You're a UML use case guy.  Great!  Wish there was more of that in
> software design, especially for tools.
> - What's the mapping from MySql YEAR to Derby?
Derby does not seem to have a YEAR data type. We can
probably use INTEGER instead....Any thoughts?

> - Can you explain a little more how DdlUtils takes care of data type
> mapping?

ddlutils tool uses JDBC datatypes rather than SQL datatypes which are
database dependent. Looking at
http://db.apache.org/ddlutils/database-support.html, explains mapping
between JDBC types and SQL types.
For example, a TIINYINT datatype from MySQL, will be mapped to SMALLINT
in Derby.

I will explain this in detail in the document.
> - Can you explain a little more what you mean by "A possible solution
> would be to execute database-specific commands to capture required
> information." when you say DdlUtils doesn't support constraints,
> triggers, stored procedures, etc.

In the case of MySQL, we can use the SHOW command to capture the exact
string to re-create the original object. For example
can be used to capture the original statement used to create function/procedure.

I will add these information to the document.
> - I guess I don't follow the application flow very well when using
> DdlUtils.  What exactly are the steps taken by the user and/or the tool
> using DdlUtils?

I probably need another usecase diagram for ddlutils. I will add that
to the document.
> - What is *your* recommended approach (DatabaseMetadata vs. DdlUtils)
> and why?
I would think a combination of ddlutils and DatabaseMetadata approach
is needed to handle cases not supported by ddlutils like stroed

I will add a section to the document on this.
> - Can you talk more to what happens if there is an error during
> migration at various phases. What steps does the tool take to set things
> right?  Can you end up with a half-created database?  What do you do to
> fix the errors and start over?  I suspect migration is often a
> repetitive effort as you catch migration/mapping errors, fix things, and
> try again...  This should be as painless as possible.

Sure, I will add this information as well.
> - Can you please show the proposed syntax and other details (input
> files, config files, env variables, exit status) for the CLI?


> - Does the CLI have a "headless" mode (e.g. no interactive prompts) so
> you can run it in a script?
Good suggestion.....I was not thinking about CLI with headless mode.
I will add information on this.

> - What is the syntax for starting the tool?  Will you make use of
> derbyrun.jar?

I will need to investigate this.

> - Can you cover quickly how you'll address internationalizing the GUI?
> - Can you explain briefly how, using this architecture, you can plug in
> other data sources besides MySQL?
> - You might want to touch on the impact to existing JDBC applications
> that are running against MySQL, which you want to migrate to Derby.  How
> are *those* migrated, and how much or how little does this tool help
> with that?  If anything, just make it clear that application migration
> is out of the scope of this tool.
> - What mechanism are you going to use to do the data transfer?  Simple
> JDBC inserts?  Bulk insert?  For large databases the mechanism you use
> can have a large impact on performance, and may actually prevent some
> databases from migrating.  It would be good to have a section on
> performance and what approaches you will take to improve performance and
> test performance.
I will add a section on performance.
> - What about migration of users, groups, permissions, etc. -- is that
> out of scope?
Good suggestion....I did not think about this.
I will add it to the docuemtn

> - Perhaps it would be good to be *very* explicit about what you plan to
> migrate and what you *don't* plan to migrate in this tool, and what you
> recommend for users for the bits that aren't being migrated
> (applications, authorizations, triggers, whatever is on that list).


> - This may not be your itch to scratch, but can you address what you're
> planning to do to (or not do) to address governmental accessibility
> requirements (called Section 508)?  See
> http://java.sun.com/products/jfc/accessibility/index.jsp.  At a minimum
> it would be great if you don't do anything that makes it difficult for
> someone else to make the tool accessible.
Ok. I will look into this.
> Thanks!
> David
> Ramin Moazeni wrote:
> > Hello,
> >
> > I am a Google Summer of code participant working on the Derby
> > Migration tool project. The High level design document is posted at
> > http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument
> >
> > There are 2 approaches described in the document -- one based on the use
> > DatabaseMetaData class and the other is based on the use ddlUtils tool
> > (http://db.apache.org/ddlutils) which is also an apache project.
> >
> > I would appreciate your feedback and comments....
> >
> > Thanks much
> > Ramin Moazeni

View raw message