[hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions)

Emmanuel Bernard emmanuel at hibernate.org
Fri Jan 15 13:51:32 EST 2010 

So after chasing bugs after bugs for 25 generations, I've got something that does not cover all cases (that are not within JPA's boundaries anyway) but at least that does not throw weird exceptions. To test it, you need to get the latest trunk of HEM and use the latest published snapshot of the static metamodel generator (jpamodelgen).

However, the Envers test still fails VersionsJoinTableRangeComponentNamingTest but with a query exception. And I am seriously doubting the validity of this test in the first place. Has it ever pass? Is it valid?

Adam, can you check it out and give us more feedback?


19:36:42,066  WARN JDBCExceptionReporter:100 - SQL Error: -28, SQLState: S0022
19:36:42,066 ERROR JDBCExceptionReporter:101 - Column not found: VJTRCTE1_ID in statement [select join_table0_.REV as col_0_0_, join_table0_.VJTRCTE1_ID as col_0_1_, join_table0_.VJTRTE_ID as col_0_2_, versionsjo1_.id as col_1_0_, versionsjo1_.REV as col_1_1_ from JOIN_TABLE_COMPONENT_1_AUD join_table0_ cross join RANGE_TEST_ENTITY_AUD versionsjo1_ where join_table0_.VJTRTE_ID=versionsjo1_.id and join_table0_.VJTRCTE1_ID=? and (versionsjo1_.REV in (select max(versionsjo2_.REV) from RANGE_TEST_ENTITY_AUD versionsjo2_ where versionsjo2_.REV<=? and versionsjo1_.id=versionsjo2_.id)) and join_table0_.REV=(select max(join_table3_.REV) from JOIN_TABLE_COMPONENT_1_AUD join_table3_ where join_table3_.REV<=? and join_table0_.VJTRCTE1_ID=join_table3_.VJTRCTE1_ID and join_table0_.VJTRTE_ID=join_table3_.VJTRTE_ID) and join_table0_.REVTYPE<>? and versionsjo1_.REVTYPE<>?]
org.hibernate.exception.SQLGrammarException: could not execute query
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.loader.Loader.doList(Loader.java:2235)
	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
	at org.hibernate.loader.Loader.list(Loader.java:2124)
	at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:416)
	at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
	at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1258)
	at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
	at org.hibernate.envers.entities.mapper.relation.lazy.initializor.AbstractCollectionInitializor.initialize(AbstractCollectionInitializor.java:62)
	at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.checkInit(CollectionProxy.java:50)
	at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.size(CollectionProxy.java:55)
	at org.hibernate.envers.test.integration.naming.VersionsJoinTableRangeComponentNamingTest.testHistoryOfUniId1(VersionsJoinTableRangeComponentNamingTest.java:165)
	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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:607)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:517)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:669)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:956)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110)
	at org.testng.TestRunner.runWorkers(TestRunner.java:759)
	at org.testng.TestRunner.privateRun(TestRunner.java:592)
	at org.testng.TestRunner.run(TestRunner.java:486)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
	at org.testng.SuiteRunner.run(SuiteRunner.java:204)
	at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:867)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:832)
	at org.testng.TestNG.run(TestNG.java:748)
	at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
	at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:79)
Caused by: java.sql.SQLException: Column not found: VJTRCTE1_ID in statement [select join_table0_.REV as col_0_0_, join_table0_.VJTRCTE1_ID as col_0_1_, join_table0_.VJTRTE_ID as col_0_2_, versionsjo1_.id as col_1_0_, versionsjo1_.REV as col_1_1_ from JOIN_TABLE_COMPONENT_1_AUD join_table0_ cross join RANGE_TEST_ENTITY_AUD versionsjo1_ where join_table0_.VJTRTE_ID=versionsjo1_.id and join_table0_.VJTRCTE1_ID=? and (versionsjo1_.REV in (select max(versionsjo2_.REV) from RANGE_TEST_ENTITY_AUD versionsjo2_ where versionsjo2_.REV<=? and versionsjo1_.id=versionsjo2_.id)) and join_table0_.REV=(select max(join_table3_.REV) from JOIN_TABLE_COMPONENT_1_AUD join_table3_ where join_table3_.REV<=? and join_table0_.VJTRCTE1_ID=join_table3_.VJTRCTE1_ID and join_table0_.VJTRTE_ID=join_table3_.VJTRTE_ID) and join_table0_.REVTYPE<>? and versionsjo1_.REVTYPE<>?]
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
	at org.hsqldb.jdbc.jdbcPreparedStatement.executeQuery(Unknown Source)
	at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
	at org.hibernate.loader.Loader.getResultSet(Loader.java:1810)
	at org.hibernate.loader.Loader.doQuery(Loader.java:697)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
	at org.hibernate.loader.Loader.doList(Loader.java:2232)
	... 33 more


On 15 janv. 2010, at 13:23, Adam Warski wrote:

> In fact I think it's a user-contributed test case.
> 
> So damn you users, damn you! ;)
> 
> Adam
> 
>> OK I've fixed this problem but only to discover another one :(
>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4805
>> 
>> Basically, Adam makes use of generics to declare its components. Since HEM's metamodel generator does not use the XLayer that resolve these generics to their value, a TypeVariable object is returned instead of a Class.
>> 
>> I'll start working on the conversion to use the XLayer and hope it resolves this problem. But that's probably a longer process.
>> 
>> Damn you Adam, damn you!
>> 
>> On 14 janv. 2010, at 15:35, Steve Ebersole wrote:
>> 
>>> Ah, backrefs!
>>> 
>>> Just disregarding them makes the most sense for sure from the JPA
>>> perspective since they are "virtual attributes" and solely a hibernate
>>> construct.
>>> 
>>> On Thu, 2010-01-14 at 11:29 +0100, Emmanuel Bernard wrote:
>>>> On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote:
>>>>> I have a couple of question regarding some recent code changes. The first one seems to be the cause of a
>>>>> test failure in VersionsJoinTableRangeComponentNamingTest (Envers). It actually causes a NullPointerException.
>>>>> Have a look at: http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main/java/org/hibernate/cfg/AbstractPropertyHolder.java?r=18518#l254
>>>> 
>>>> Right, I fixed the problem, sorry about that.
>>>> Though it uncovered a weird problem.
>>>> When I run the entire envers test suite, I pass with flags up.
>>>> When I specifically run VersionsJoinTableRangeComponentNamingTest
>>>> I've got a 
>>>> java.lang.IllegalArgumentException: Cannot determine java-type from given member [null]
>>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:591)
>>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:671)
>>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:661)
>>>> 	at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:542)
>>>> 	at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:81)
>>>> 	at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:177)
>>>> 	at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66)
>>>> 	at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:79)
>>>> 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:752)
>>>> 	at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:94)
>>>> 	at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:82)
>>>> 
>>>> The member is null because the "property" has a backref getter and hence no member is returned by NORMAL_MEMBER_RESOLVER. I think we should ignore backref properties
>>>> 
>>>> Does that make sense? If we agree, I will go and apply a fix.
>>>> 
>>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4797
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> Also have a look at http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main/java/org/hibernate/cfg/AnnotationConfiguration.java?r=18506#l896
>>>>> You create a AssertionFailure, but then don't throw it? I guess this is just missing a 'throw' before the new.
>>>> 
>>>> yep, fixed.
>>> -- 
>>> Steve Ebersole <steve at hibernate.org>
>>> Hibernate.org
>>> 
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

More information about the hibernate-dev mailing list