DDL generation woes (again)

[ljnelson]

I finally figured out why EclipseLink's DDL generation has been bothering me.  It is unpredictable.

That is, when I have eclipselink.ddl-generation set to create-tables or drop-and-create-tables, sometimes it will correctly manufacture all the tables in my H2 database, and sometimes it will bomb out with:

Caused by: Exception [EclipseLink-7008] (Eclipse Persistence Services - 1.1.2.v20090730-r4753): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The Java type [null] is not a valid database type.

To re-emphasize: if I run my unit tests 10 times, I may get 10 successes, or I may get 7, or 3, or....

I've been tracking this through https://bugs.eclipse.org/bugs/show_bug.cgi?id=282075, but I think the problem is probably deeper.

Does anyone have any thoughts on this issue?  Does DDL generation involve multithreading, or concurrency problems?

Thanks,
Laird

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[James Sutherland]

Very odd, could you include the full exception stack trace.  Also if you can narrow it down to which class/mappings are causing the issue, please include these.

ljnelson wrote:

I finally figured out why EclipseLink's DDL generation has been bothering
me.  It is unpredictable.

That is, when I have eclipselink.ddl-generation set to create-tables or
drop-and-create-tables, sometimes it will correctly manufacture all the
tables in my H2 database, and sometimes it will bomb out with:

Caused by: Exception [EclipseLink-7008] (Eclipse Persistence Services -
1.1.2.v20090730-r4753):
org.eclipse.persistence.exceptions.ValidationException
Exception Description: The Java type [null] is not a valid database type.

To re-emphasize: if I run my unit tests 10 times, I may get 10 successes, or
I may get 7, or 3, or....

I've been tracking this through
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282075, but I think the
problem is probably deeper.

Does anyone have any thoughts on this issue?  Does DDL generation involve
multithreading, or concurrency problems?

Thanks,
Laird

[ljnelson]

On Thu, Sep 24, 2009 at 10:11 AM, James Sutherland <jamesssss@...> wrote:

Very odd, could you include the full exception stack trace.

Here's the full stack (stand back):

Exception Description: The Java type [null] is not a valid database type.
    at org.eclipse.persistence.exceptions.ValidationException.javaTypeIsNotAValidDatabaseType(ValidationException.java:1172)
    at org.eclipse.persistence.tools.schemaframework.FieldDefinition.appendDBString(FieldDefinition.java:137)
    at org.eclipse.persistence.tools.schemaframework.TableDefinition.buildCreationWriter(TableDefinition.java:306)
    at org.eclipse.persistence.tools.schemaframework.DatabaseObjectDefinition.createOnDatabase(DatabaseObjectDefinition.java:81)
    at org.eclipse.persistence.tools.schemaframework.SchemaManager.createObject(SchemaManager.java:187)
    at org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceObject(SchemaManager.java:882)
    at org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTablesAndConstraints(TableCreator.java:297)
    at org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTables(TableCreator.java:260)
    at org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceDefaultTables(SchemaManager.java:944)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.createOrReplaceDefaultTables(EntityManagerFactoryProvider.java:78)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.writeDDLToDatabase(EntityManagerFactoryProvider.java:286)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.generateDDL(EntityManagerFactoryProvider.java:115)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:260)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:111)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:163)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:150)
    at ljnelson.AbstractJPATestCase.initEntityManager(AbstractJPATestCase.java:62)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
    at org.junit.runners.Suite.runChild(Suite.java:117)
    at org.junit.runners.Suite.runChild(Suite.java:24)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
    at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)

 

 Also if you can
narrow it down to which class/mappings are causing the issue, please include
these.

It (a) is not reported and (b) doesn't seem to matter.  Additionally, since the failures happen sporadically, it's impossible to tell reliably which classes have caused the problem.

I can say that I make heavy use of columnDefinition, length and nullable in my @Column annotations, and there are all sorts of problems with these in general.  For example, placing a columnDefinition on a @Column annotation that is used to annotate an @Id column fails.  I also tend to redundantly specify lengths in both the length attribute and the columnDefinition.  For example, I might annotate a column like this:

@Column(name = "frob", length = 4, columnDefinition = "CHAR(4)", nullable = false)
private String foobar;

...since it is important that the DDL that results be of type CHAR, not VARCHAR, which is the default.  I haven't found a way to specify the database type without also including the length in the columnDefinition fragment.  This snippet (above) works fine in Hibernate and OpenJPA.

Anyhow, in general, removing these attributes tends to improve things (but not definitively solve the problem).
 
About the only thing I could do is zip up my project (which is somewhere between small and large) and send it your way.

Best,
Laird

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[James Sutherland]

For some reason the type for the column is null, so was not able to be determined.  Do you have any mapped fields of type Object or that use a TransformationMapping?

Without the mapping causing the issue, the issue is difficult to determine.  You may want to try putting a break-point in to find what field/table/class is causing the issue an include its mappings.  Or if you have an Oracle support contract, you may wish to contact Oracle support.

The error message should include the field/table though, so please log a bug for this.

Also, if you have not done so, you may wish to try the latest build, to see if the issue has been fixed.

ljnelson wrote:

On Thu, Sep 24, 2009 at 10:11 AM, James Sutherland <[e-mail]>wrote:

> Very odd, could you include the full exception stack trace.


Here's the full stack (stand back):

Exception Description: The Java type [null] is not a valid database type.
    at
org.eclipse.persistence.exceptions.ValidationException.javaTypeIsNotAValidDatabaseType(ValidationException.java:1172)
    at
org.eclipse.persistence.tools.schemaframework.FieldDefinition.appendDBString(FieldDefinition.java:137)
    at
org.eclipse.persistence.tools.schemaframework.TableDefinition.buildCreationWriter(TableDefinition.java:306)
    at
org.eclipse.persistence.tools.schemaframework.DatabaseObjectDefinition.createOnDatabase(DatabaseObjectDefinition.java:81)
    at
org.eclipse.persistence.tools.schemaframework.SchemaManager.createObject(SchemaManager.java:187)
    at
org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceObject(SchemaManager.java:882)
    at
org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTablesAndConstraints(TableCreator.java:297)
    at
org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTables(TableCreator.java:260)
    at
org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceDefaultTables(SchemaManager.java:944)
    at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.createOrReplaceDefaultTables(EntityManagerFactoryProvider.java:78)
    at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.writeDDLToDatabase(EntityManagerFactoryProvider.java:286)
    at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.generateDDL(EntityManagerFactoryProvider.java:115)
    at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:260)
    at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:111)
    at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:163)



>  Also if you can
> narrow it down to which class/mappings are causing the issue, please
> include
> these.
>

It (a) is not reported and (b) doesn't seem to matter.  Additionally, since
the failures happen sporadically, it's impossible to tell reliably which
classes have caused the problem.

I can say that I make heavy use of columnDefinition, length and nullable in
my @Column annotations, and there are all sorts of problems with these in
general.  For example, placing a columnDefinition on a @Column annotation
that is used to annotate an @Id column fails.  I also tend to redundantly
specify lengths in both the length attribute and the columnDefinition.  For
example, I might annotate a column like this:

@Column(name = "frob", length = 4, columnDefinition = "CHAR(4)", nullable =
false)
private String foobar;

...since it is important that the DDL that results be of type CHAR, not
VARCHAR, which is the default.  I haven't found a way to specify the
database type without also including the length in the columnDefinition
fragment.  This snippet (above) works fine in Hibernate and OpenJPA.

Anyhow, in general, removing these attributes tends to improve things (but
not definitively solve the problem).

About the only thing I could do is zip up my project (which is somewhere
between small and large) and send it your way.

Best,
Laird

[ljnelson]

Hi, James, indeed, the table name is nowhere to be found.

In addition, I can run this build several times in a row without changing anything, and sometimes it works, and sometimes it does not.

There are no TransformationMappings.

I hope this helps.

Best,
Laird

On Tue, Sep 29, 2009 at 10:14 AM, James Sutherland <jamesssss@...> wrote:

For some reason the type for the column is null, so was not able to be
determined.  Do you have any mapped fields of type Object or that use a
TransformationMapping?

Without the mapping causing the issue, the issue is difficult to determine.
You may want to try putting a break-point in to find what field/table/class
is causing the issue an include its mappings.  Or if you have an Oracle
support contract, you may wish to contact Oracle support.

The error message should include the field/table though, so please log a bug
for this.

Also, if you have not done so, you may wish to try the latest build, to see
if the issue has been fixed.

ljnelson wrote:
>
> On Thu, Sep 24, 2009 at 10:11 AM, James Sutherland
> <jamesssss@...>wrote:
>
>> Very odd, could you include the full exception stack trace.
>
>
> Here's the full stack (stand back):
>
> Exception Description: The Java type [null] is not a valid database type.
>     at
> org.eclipse.persistence.exceptions.ValidationException.javaTypeIsNotAValidDatabaseType(ValidationException.java:1172)
>     at
> org.eclipse.persistence.tools.schemaframework.FieldDefinition.appendDBString(FieldDefinition.java:137)
>     at
> org.eclipse.persistence.tools.schemaframework.TableDefinition.buildCreationWriter(TableDefinition.java:306)
>     at
> org.eclipse.persistence.tools.schemaframework.DatabaseObjectDefinition.createOnDatabase(DatabaseObjectDefinition.java:81)
>     at
> org.eclipse.persistence.tools.schemaframework.SchemaManager.createObject(SchemaManager.java:187)
>     at
> org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceObject(SchemaManager.java:882)
>     at
> org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTablesAndConstraints(TableCreator.java:297)
>     at
> org.eclipse.persistence.tools.schemaframework.TableCreator.replaceTables(TableCreator.java:260)
>     at
> org.eclipse.persistence.tools.schemaframework.SchemaManager.replaceDefaultTables(SchemaManager.java:944)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.createOrReplaceDefaultTables(EntityManagerFactoryProvider.java:78)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.writeDDLToDatabase(EntityManagerFactoryProvider.java:286)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.generateDDL(EntityManagerFactoryProvider.java:115)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:260)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:111)
>     at
> org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:163)
>
>
>

>>  Also if you can
>> narrow it down to which class/mappings are causing the issue, please
>> include
>> these.
>>
>
> It (a) is not reported and (b) doesn't seem to matter.  Additionally,
> since
> the failures happen sporadically, it's impossible to tell reliably which
> classes have caused the problem.
>
> I can say that I make heavy use of columnDefinition, length and nullable
> in
> my @Column annotations, and there are all sorts of problems with these in
> general.  For example, placing a columnDefinition on a @Column annotation
> that is used to annotate an @Id column fails.  I also tend to redundantly
> specify lengths in both the length attribute and the columnDefinition.
> For
> example, I might annotate a column like this:
>
> @Column(name = "frob", length = 4, columnDefinition = "CHAR(4)", nullable
> =
> false)
> private String foobar;
>
> ...since it is important that the DDL that results be of type CHAR, not
> VARCHAR, which is the default.  I haven't found a way to specify the
> database type without also including the length in the columnDefinition
> fragment.  This snippet (above) works fine in Hibernate and OpenJPA.
>
> Anyhow, in general, removing these attributes tends to improve things (but
> not definitively solve the problem).
>
> About the only thing I could do is zip up my project (which is somewhere
> between small and large) and send it your way.
>
> Best,
> Laird
>
>

-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--

View this message in context: http://www.nabble.com/DDL-generation-woes-%28again%29-tp25548248p25663834.html

Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users