You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Michael Dick (JIRA)" <ji...@apache.org> on 2007/11/29 00:15:44 UTC
[jira] Resolved: (OPENJPA-455) Incorrect MySQL DDL Generation for
integer types
[ 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (OPENJPA-455) Incorrect MySQL DDL Generation
for integer types
Posted by Tim Holloway <ti...@mousetech.com>.
On Thu, 2007-11-29 at 16:26 +0700, Patrick Linskey wrote:
> Hi,
>
> Thanks for the analysis.
>
You're welcome.
> > 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?
If you manually add column definitions to a schema.xml in the middle of
a table definition, the columns will be added to the end of the actual
database schema, not inserted between existing columns in the same order
as the schema indicates.
>
> -Patrick
>
> On Nov 29, 2007 9:15 AM, Tim Holloway <ti...@mousetech.com> 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
> > >
> >
> >
>
>
>
Re: [jira] Resolved: (OPENJPA-455) Incorrect MySQL DDL Generation for integer types
Posted by Patrick Linskey <pl...@gmail.com>.
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 <ti...@mousetech.com> 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
Re: [jira] Resolved: (OPENJPA-455) Incorrect MySQL DDL Generation
for integer types
Posted by Tim Holloway <ti...@mousetech.com>.
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
>