Hi David, Thanks for your comments. My comments inline....
Thanks, Ramin 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?
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 SHOW CREATE PROCEDURE or SHOW CREATE FUNCTION 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 procedures. 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?
Ok.
- 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?
Sure
- Can you explain briefly how, using this architecture, you can plug in other data sources besides MySQL?
Ok.
- 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.
Ok
- 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).
Ok
- 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