db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Satheesh Bandaram" <banda...@gmail.com>
Subject Re: MySQL to Derby Migration Tool
Date Wed, 28 Jun 2006 01:06:29 GMT
Great document and good comments from David. I think it would be good to
follow ddlUtils approach (approach 2) if feasible. Ramin, should this
approach be also discussed on ddlUtils development alias?

I think you would need to handle some database objects like CHECK
constraints and others in a database specific way in either approach.
DatabaseMetadata doesn't provide a way and probably why ddlUtil doesn't
support that either. These objects will have to be migrated by reading
source database specific system tables... so your generic migration tool
would probably need a source database specific plug-in...

I would also like to encourage others to review the document as Ramin seems
to be making good progress towards implementation.


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?
> - Can you explain a little more how DdlUtils takes care of data type
> mapping?
> - 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.
> - 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?
> - What is *your* recommended approach (DatabaseMetadata vs. DdlUtils)
> and why?
> - 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.
> - 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?
> - What is the syntax for starting the tool?  Will you make use of
> derbyrun.jar?
> - 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.
> - What about migration of users, groups, permissions, etc. -- is that
> out of scope?
> - 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.
> 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