Hi, Thanks for the analysis.
> Come to think of it, this also implies that a column insert operation > would be flawed. Which, I've just verified, is true. What do you mean by this? -Patrick On Nov 29, 2007 9:15 AM, Tim Holloway <[EMAIL PROTECTED]> wrote: > That was fast! > > I tried it and eyeballed the results - haven't had a chance to feed it > to a live database yet, but it looks good. Only possible problem is I'm > not sure if the schema XML type-name attributes are OK, but that's just > because I'm not sure what "OK" was supposed to look like anyway. > > Observation: > > If you modify a schema.xml to rename a field, the results of the > schematool are exactly as advertised. However, "as advertised" means > that the operation is performed as an alter table Drop Field followed by > an alter table Add Field. > > The only problem with this is that since SQL databases have a specific > column order, and the Add Field adds the newly-renamed field to the end > of the table column list, the results are not the same as a true column > rename operation - and the schema XML file won't agree with the actual > schema on column order. > > This merits consideration for a future schematool release. Depending on > the DBMS, a more accurate operation would be: > > 1. Alter table rename column > > 2. Alter table Drop column; alter table Insert Column before/after > original-predecessor-or-successor-column > > 3. Alter table Drop Column; Alter table Insert Column (at end) because > your DBMS isn't smart enough to do better. Assuming that even these > operations are possible on it. > > Come to think of it, this also implies that a column insert operation > would be flawed. Which, I've just verified, is true. > > Tim > > > > On Wed, 2007-11-28 at 15:15 -0800, Michael Dick (JIRA) wrote: > > [ > > https://issues.apache.org/jira/browse/OPENJPA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > > > Michael Dick resolved OPENJPA-455. > > ---------------------------------- > > > > Resolution: Fixed > > Fix Version/s: 1.1.0 > > Assignee: Michael Dick > > > > > Incorrect MySQL DDL Generation for integer types > > > ------------------------------------------------ > > > > > > Key: OPENJPA-455 > > > URL: https://issues.apache.org/jira/browse/OPENJPA-455 > > > Project: OpenJPA > > > Issue Type: Bug > > > Affects Versions: 1.0.0, 1.0.1 > > > Reporter: Michael Dick > > > Assignee: Michael Dick > > > Fix For: 1.1.0 > > > > > > Attachments: OPENJPA-455.patch.txt > > > > > > > > > Opening a JIRA report on Tim's behalf. > > > I turned the schema tool loose on a MySQL production database this > > > afternoon and it failed. The essence of the problem appears that DDL was > > > being generated with a type declaration of this form: > > > int unsigned(10) > > > In MySQL, the proper form is: > > > int(10) unsigned > > > viz: > > > ALTER TABLE fubar MODIFY col1 int(10) unsigned; > > > Checking other options indicates that similar constructs such as CREATE > > > TABLE are likewise defective. > > > I looked at the svn trunk head source code in > > > org.apache.openjpa.jdbc.sql.MySQLDictionary.java and the parent class > > > DBDictionary.java. The offending method appears to be: > > > 1508: public String getTypeName(Column col) > > > This method has no override in MySQLDictionary, but apparently needs > > > one. I think it's a minor mod, but I'm not currently set up to build and > > > test in the environment where the offending database exists. > > > This is a SEVERE error. It causes generation of defective SQL for > > > SQL-generating options and causes live updates to schemas to fail. > > > I don't have a Jira login at present, so if someone could log this, it > > > would be appreciated. > > > Thanks, > > > Tim Holloway > > > > -- Patrick Linskey 202 669 5907
