[Hibernate-JIRA] Created: (HHH-5488) Hibernate fails with two kinds of exceptions on a compsite-key join table that references two composite keys (one column shared by both foreign keys)
by Karsten Wutzke (JIRA)
Hibernate fails with two kinds of exceptions on a compsite-key join table that references two composite keys (one column shared by both foreign keys)
-----------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-5488
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5488
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, entity-manager
Affects Versions: 3.6.0.Beta2, 3.5.4
Environment: Windows 7 64bit, localhost, Tomcat 6, embedded JBoss, Hibernate 3.5.4 and 3.6.0 Beta2, MySQL 5.1.46
Reporter: Karsten Wutzke
Priority: Blocker
Hibernate fails with two kinds of exceptions on a compsite-key join table that references two composite keys (one column shared by both foreign keys): see ZipArea.java and PostAddress.java inside the attached file
1. When having both entity classes use the annotations as they should be (ZipArea having @Entity and @Table, PostAddress association having @ManyToOne and @JoinColumns) then I get:
18.08.2010 18:22:51 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Geo Info Test Servlet as unavailable
18.08.2010 18:22:51 org.apache.catalina.core.StandardContext loadOnStartup
SCHWERWIEGEND: Servlet /geoinfotest threw load() exception
org.hibernate.MappingException: Unable to find column with logical name: state_code in ZipAreas
at org.hibernate.cfg.Ejb3JoinColumn.checkReferencedColumnsType(Ejb3JoinColumn.java:573)
at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:125)
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:110)
at org.hibernate.cfg.Configuration.processEndOfQueue(Configuration.java:1618)
at org.hibernate.cfg.Configuration.processFkSecondPassInOrder(Configuration.java:1541)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1457)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1413)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1453)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1081)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:275)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:359)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at geoinfotest.GeoInfoTestServlet.<init>(GeoInfoTestServlet.java:16)
...
This is the most constant and frequent error. Note though, when I removed all the INDEXes from the database it sometimes happens that Hibernate can't find the column in Cities:
18.08.2010 19:37:43 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Geo Info Test Servlet as unavailable
18.08.2010 19:37:43 org.apache.catalina.core.StandardContext loadOnStartup
SCHWERWIEGEND: Servlet /geoinfotest threw load() exception
org.hibernate.MappingException: Unable to find column with logical name: state_code in Cities
at org.hibernate.cfg.Ejb3JoinColumn.checkReferencedColumnsType(Ejb3JoinColumn.java:573)
at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:125)
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:110)
at org.hibernate.cfg.Configuration.processEndOfQueue(Configuration.java:1618)
at org.hibernate.cfg.Configuration.processFkSecondPassInOrder(Configuration.java:1541)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1457)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1413)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1453)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1081)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:275)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:359)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at geoinfotest.GeoInfoTestServlet.<init>(GeoInfoTestServlet.java:16)
...
2. When outcommenting PostAddress's @ManyToOne and @JoinColumns on zipArea and leaving @Entity and @Table on ZipArea class, I get the following exception:
18.08.2010 18:05:02 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Geo Info Test Servlet as unavailable
18.08.2010 18:05:02 org.apache.catalina.core.StandardContext loadOnStartup
SCHWERWIEGEND: Servlet /geoinfotest threw load() exception
org.hibernate.AnnotationException: referencedColumnNames(country_code, state_code, name) of geoinfotest.ZipArea.city referencing geoinfotest.City not mapped to a single property
at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:204)
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:110)
at org.hibernate.cfg.Configuration.processEndOfQueue(Configuration.java:1618)
at org.hibernate.cfg.Configuration.processFkSecondPassInOrder(Configuration.java:1541)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1457)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1413)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1453)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1081)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:275)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:359)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at geoinfotest.GeoInfoTestServlet.<init>(GeoInfoTestServlet.java:16)
...
I have no idea what's going on. The special situation of the ZipAreas join table is that it references country_code of both tables. As a result, I have only *one* country_code column, which is used twice by ZipArea's foreign keys. Maybe that's confusing Hibernate. I can only guess. The strange thing is that Hibernate fails with City not being mapped to a single property *or* not being able to map state_code. My assumption is that Hibernate gobbles on that special design in conjunction with indexes. Just guessing though.
Here's my original forum post: https://forum.hibernate.org/viewtopic.php?f=1&t=1006411
The DB design can be viewed here: http://www.kawoolutions.com/media/geoinfo.pdf
I have attached a ZIP of the test project including an Ant build script (including deploy-local, undeploy-local, and redeploy-local targets using the Tomcat deployment tasks). I outcommented the Tomcat deploy task setup and targets.
Use "ant war" to build the distribution WAR file. I also put a MySQL DDL script into the db dir, including the above PDF, and a MySQL Workbench model. The example doesn't need data to fail. The DB name is "geoinfo". Just set your MySQL DB username and password in xml/persistence.xml (I think it's not even needed).
--
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, 3 months
[Hibernate-JIRA] Created: (METAGEN-54) XML-only field access type Set attribute not generated
by Martijn Blankestijn (JIRA)
XML-only field access type Set attribute not generated
------------------------------------------------------
Key: METAGEN-54
URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-54
Project: Hibernate Metamodel Generator
Issue Type: Bug
Components: processor
Affects Versions: 1.1.1.Final
Environment: maven 3.0.2
Java: java version "1.6.0_22", Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Uname: Linux xxx 2.6.32-28-generic-pae #55-Ubuntu SMP Mon Jan 10 22:34:08 UTC 2011 i686 GNU/Linux
Reporter: Martijn Blankestijn
Assignee: Hardy Ferentschik
Attachments: 0001-XML-only-field-access-type-Set-attribute-not-generat.patch
I have a xml-only mapping with no target-entity attribute specified on collections. For the collections generics were used, so type information was available. The collections were not generated by the generator in the meta-model classes.
I have checked out the current version of the source from Git and made the changes (testcases and solution). You find these files attached to this bugreport. It is not a very 'clean' solution yet, but I wanted to shared the bug and possible solution first.
When I run maven just after checkout I had 4 failing testcases:
testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
testDefaultAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
testExplicitXmlConfiguredAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
I still had these 4 failing testcase with my solution and I have not investigated this further.
In my search for the answer (error in my mapping, incorrect understanding of the generator or a bug in the Generator) I found a couple of points I got confused about.
First is that the access type on the XML entity was not set if it was specified only on the entity (not in the persistence unit default or on the collection itself). It then defaulted to METHOD (a.k.a. property access)
In XmlMetaEntity (line 542)
return TypeUtils.getElementKindForAccessType( accessTypeInfo.getDefaultAccessType() );
probably should be
return TypeUtils.getElementKindForAccessType( accessTypeInfo.getAccessType() );
which was good because line 196 would lead the code to look for attributes (not methods) to compare to the property-name.
If the element was not the same one as was expected, the loop would skip that element. This seemed strange to me.
if ( expectedElementKind.equals( elem.getKind() ) ) {
continue;
}
As I said, attached is my solution in which, I hope, will confirm to the JPA-specification ;-).
Regards,
Martijn Blankestijn
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-5968) Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType
by Gail Badner (JIRA)
Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType
-----------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-5968
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5968
Project: Hibernate Core
Issue Type: Deprecation
Components: core
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.6.2
UserType.nullSafeGet() and nullSafeSet() methods will be deprecated because they do not take a SessionImplementor argument:
public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
public void nullSafeSet(PreparedStatement st, Object value, int index)
They will be replaced by methods taking a SessionImplementor argument in Hibernate 4. These new methods will not be added to UserType because doing so would break everyone's UserType implementation.
In AbstractSingleColumnStandardBasicType, the following methods will be deprecated:
public T nullSafeGet(ResultSet rs, String name)
public Object get(ResultSet rs, String name)
public void nullSafeSet(PreparedStatement st, T value, int index)
public void set(PreparedStatement st, T value, int index)
These methods should have been deprecated in AbstractSingleColumnStandardBasicType when their super methods in SingleColumnType were deprecated (the deprecation did not come across in Javadoc generated by {@inheritDoc}).
The following methods should be used instead:
AbstractSingleColumnStandardBasicType.nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session)
AbstractStandardBasicType.nullSafeGet(ResultSet rs, String name, SessionImplementor session, Object owner)
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-3836) composite-element with null columns in map is ignored
by Benoit Goudreault-Emond (JIRA)
composite-element with null columns in map is ignored
-----------------------------------------------------
Key: HHH-3836
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3836
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.SP1
Environment: 3.3.0 SP1, noticed with Oracle and H2 but probably happens with all databases
Reporter: Benoit Goudreault-Emond
Attachments: patate.zip
When a composite element with all properties set to NULL is inserted in a map of the said composite element, the data gets inserted to the database but is never retreived when reloading the entity.
For instance, with an entity
@Entity
public class TestEntity {
@Id
private int id;
@CollectionOfElements
private Map<String, AccessPeriod> roleAccesses = new HashMap<String, AccessPeriod>();
// boilerplate getters/setters/etc omitted
}
And AccessPeriod being
@Embeddable
public class AccessPeriod {
public Date startDate;
public Date endDate;
}
If you insert in the map an AccessPeriod with both startDate and endDate set to null and persist the TestEntity,
an entry is inserted in the auxiliary table, but when getting the TestEntity back, the map is empty.
You get the same problem with a mapping file.
This used to work in Hibernate 2.1--I found this out while porting some code to 3.3.
See the attached example. You'll need to include Hibernate and h2 (com.h2database:h2 1.0.20061217) on your classpath to run it with the given jdbc.properties, but feel free to change it.
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-5801) ColumnNameCache.columnNameToIndexCache map should be synchronized
by Ivan Popov (JIRA)
ColumnNameCache.columnNameToIndexCache map should be synchronized
-----------------------------------------------------------------
Key: HHH-5801
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5801
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.2.7
Environment: AIX, IMB J9 jvm
Reporter: Ivan Popov
When I activate the result set wapper, hibernate.jdbc.wrap_result_sets=true, I can have a stacktrace such as :
####<Dec 15, 2010 8:44:27 PM CET> <Error> <WebLogicServer> <efa-bench> <decalog_server> <[ACTIVE] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1292442267345> <BEA-000337> <[STUCK] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy
for "602" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@73907390", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.util.HashMap.findNonNullKeyEntry(HashMap.java:526)
java.util.HashMap.getEntry(HashMap.java:510)
java.util.HashMap.get(HashMap.java:496)
org.hibernate.jdbc.ColumnNameCache.getIndexForColumnName(ColumnNameCache.java:52)
org.hibernate.jdbc.ResultSetWrapper.findColumn(ResultSetWrapper.java:84)
org.hibernate.jdbc.ResultSetWrapper.getString(ResultSetWrapper.java:248)
org.hibernate.type.StringType.get(StringType.java:18)
org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154)
org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2091)
org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
org.hibernate.loader.Loader.getRow(Loader.java:1206)
org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
org.hibernate.loader.Loader.doQuery(Loader.java:701)
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
org.hibernate.loader.Loader.loadCollection(Loader.java:1998)
org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:63)
org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1717)
org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109)
org.hibernate.collection.PersistentSet.size(PersistentSet.java:139)
I think that columnNameToIndexCache map should be synchronized.
I got the exception with 3.2.7 but I had a look at the latest version and the bug is still there.
--
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, 4 months