db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: MySQL to Derby Migration Tool
Date Tue, 27 Jun 2006 22:03:12 GMT
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 

- 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 

- 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.



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