[Hibernate-JIRA] Created: (HHH-5086) "ambiguous column" SQL errors in Hibernate 3.5.0 Final
by dnalos (JIRA)
"ambiguous column" SQL errors in Hibernate 3.5.0 Final
------------------------------------------------------
Key: HHH-5086
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5086
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Final
Environment: Java JDK 1.6.0_19
Hibernate Core 3.5.0 Final
hibernate-jpa-2.0-api-1.0.0.Final.jar
mysql-connector-java-5.1.10-bin.jar
Reporter: dnalos
Attachments: HibernateAmbiguousTest.zip
After update Hibernate Core to 3.5, we get some Exception like this:
Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101)
We create a testcase for you, and the Exception from the testcase:
ERROR 15:39:28 0 Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101)
org.hibernate.exception.ConstraintViolationException: could not load an entity: [Invoice#401]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1937)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3270)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1080)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:997)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:990)
at HibernateAmbiguousTest.testAmbiguous(HibernateAmbiguousTest.java:55)
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.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column '_value' in field list is ambiguous
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.Util.getInstance(Util.java:381)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1849)
at org.hibernate.loader.Loader.doQuery(Loader.java:718)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1933)
... 34 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-5409) bag and idbag should implement equals() and hashCode() the same way as other collections
by Dmitry Katsubo (JIRA)
bag and idbag should implement equals() and hashCode() the same way as other collections
----------------------------------------------------------------------------------------
Key: HHH-5409
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Dmitry Katsubo
bags/idbags behave in inconsistent way in comparison to set/list/map in respect to {{equals()}} and {{hashCode()}}.
In {{[PersistentBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentBag.java?r=HEAD#l510]}} {{equals()}} and {{hashCode()}} methods are commented and in {{[PersistentIdentifierBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentIdentifierBag.java?r=HEAD]}} not present.
{{[PersistentMap.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentMap.java?r=HEAD#l449]}}, {{[PersistentSet.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentSet.java?r=HEAD#l428]}}, {{[PersistentList.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentList.java?r=HEAD#l484]}} however implement {{equals()}} and {{hashCode()}} methods correctly.
The intention of this is clear: to avoid loading of the lazy collection on simple {{equals()}} call.
* I think that it is a task for the end application to handle lazy collections as it is aware about this situation.
* If there is a strong demand of not loading collections on {{equals()}} call for some applications, I suggest to make this behaviour configurable via additional attribute in XML mapping for all collections.
* The behaviour should be documented as suggested in HHH-1642. I personally spend hours debugging before I understood why lists behave differently from bags.
Probably relative issues:
* HHH-3771 ({{equals()}} for lazy loaded objects)
* HHH-1642 ({{equals()}} for {{[AbstractPersistentCollection.SetProxy|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/AbstractPersistentCollection.java?r=HEAD#l636]}})
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-5454) With hibernate.order_inserts=true Hibernate executes SQL inserts in wrong order
by Oleg Tsernetsov (JIRA)
With hibernate.order_inserts=true Hibernate executes SQL inserts in wrong order
-------------------------------------------------------------------------------
Key: HHH-5454
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5454
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0.Beta2, 3.3.2, 3.3.1, 3.3.0.SP1
Environment: Initially occurred with hibernate-core 3.3.1, Oracle 11g.
Reproduced with hibernate-core 3.3.0 SP1 (and later) and HSQLDB 2.0.0
Reporter: Oleg Tsernetsov
Attachments: jpatest.zip
*General:*
With _hibernate.order_inserts_ configuration property set to _true_ Hibernate executes SQL inserts in wrong order, so that dependent entities are attempted to be inserted before parent entities. This is a production case, so we had to switch off hibernate insert ordering to workaround the problem.
*Test case:*
Test case for reproduce is attached (jpatest.zip). It uses hibernate-entitymanager 3.4.0.GA (hibernate-core 3.3.0 SP1), hsqldb 2.0.0. The problem is also reproducible in later versions of hibernate-core (3.3.1, 3.3.2, 3.6.0.Beta2).
Test case is a typical maven2 project.
In order to run the test case:
- unzip the archive to any folder
- cd jpatest
- mvn test
If change hibernate.order_inserts to _false_ in /jpatest/src/main/resources/META-INF/persistence.xml, then the test passes.
Mappings are located under \jpatest\src\main\resources\META-INF\mappings.hbm.xml
*Data model:*
[Person] 1 -- * [Phone]
[Person] 1 -- * [Relation] * -- 1 [Person]
*Scenario:*
1) Insert plain person P1.
2) Update person P1,
-- add new phone PH1 to person P1
-- add new relation R1 to person P1. Relation R1 refers to a new person P2 having new phone PH2 Update of person P1 generates insert for phone PH1 and cascade inserts for P2, PH2 and R1.
Once inserts are ordered, insert clauses for phones PH1 and PH2 come first. As insert for PH2 is executed before the insert of its parent entity P2, the whole operation fails due to parent key not found.
With Oracle DB it results in java.sql.BatchUpdateException: ORA-02291: integrity constraint (PHONE_PERSON_FK) violated - parent key not found
With HSQLDB - java.sql.BatchUpdateException: integrity constraint violation: foreign key no parent; PHONE_PERSON_FK table: PHONE
*Problematic code*
org.hibernate.engine.ActionQueue.InsertActionSorter.findBatchNumber(), uses only _property_ types to determine batch number, but in given case cascade goes through composite primary key of Phone, so the code should also deep-traverse action.getPersister().getClassMetadata().getIdentifierType().
*Another problem*
When I tried to change phone collection mapping in Person entity from _<map>_ to _<set>_ (with hope to workaround the issue), then I got another error:
java.lang.NullPointerException
at org.hibernate.type.AbstractType.getHashCode(AbstractType.java:136)
at org.hibernate.type.AbstractType.getHashCode(AbstractType.java:144)
at org.hibernate.type.EntityType.getHashCode(EntityType.java:312)
at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:212)
at org.hibernate.engine.EntityKey.generateHashCode(EntityKey.java:126)
at org.hibernate.engine.EntityKey.<init>(EntityKey.java:70)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:184)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsPersistent(DefaultPersistEventListener.java:134)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:107)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
at com.test.AppTest.testJPA(AppTest.java:77)
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 junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Please pay attention to it as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
by Dan Bisalputra (JIRA)
Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
-----------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC
Reporter: Dan Bisalputra
Priority: Minor
When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context.
This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month