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.
Satheesh
On 6/27/06,
David Van Couvering <[EMAIL PROTECTED]> 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
