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:27:44 GMT
Hi Satheesh

Thanks for your comments....I will post the document ddlutils-dev alias
as well.

Thanks,
Ramin

On 6/27/06, Satheesh Bandaram <bandaram@gmail.com> wrote:
> 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.
>
> Satheesh
>
>
> 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
> >
>
>

Mime
View raw message