[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: (HHH-6669) Manual SchemaExport broken due to temp code comments
by Christian Bauer (JIRA)
Manual SchemaExport broken due to temp code comments
----------------------------------------------------
Key: HHH-6669
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6669
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 4.0.0.CR3
Reporter: Christian Bauer
Priority: Minor
Commit introducing the problem: 88543c7a585dbafe6d2f5e2824a9754ec419655f
In ManagedProviderConnectionHelper.java:
public void prepare(boolean needsAutoCommit) throws SQLException {
/* TEMP TEMP TEMP
connectionProvider = ConnectionProviderBuilder.buildConnectionProvider();
connection = connectionProvider.getConnection();
if ( needsAutoCommit && !connection.getAutoCommit() ) {
connection.commit();
connection.setAutoCommit( true );
}
*/
}
This breaks "new SchemaExport(configuration)" calls.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[Hibernate-JIRA] Reopened: (HHH-891) SET CHAINED command not allowed within multi-statement transaction
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-891?page=co... ]
Steve Ebersole reopened HHH-891:
--------------------------------
> SET CHAINED command not allowed within multi-statement transaction
> ------------------------------------------------------------------
>
> Key: HHH-891
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-891
> Project: Hibernate Core
> Issue Type: Bug
> Environment: Sybase 12.5, IBM Rational Application developer and WAS 6.0, Windows XP development stations. We'reusing latest verions of Spring. The JDBC Driver is JConnect 5.5
> Reporter: Harry Grongstad
> Priority: Blocker
>
> We are using the OpenSessionInView filter to open the Hibernate session, we call a service layer to load *most* data and that layer has transactional methods ( findXXX() ). The OpenSessionInView implementation we use starts a transaction (JTA). The service layer uses "REQUIRES NEW" as trasnaction attribute.
> The problem "ERROR JDBCExceptionReporter:58 - SET CHAINED command not allowed within multi-statement transaction" which was reported before in another JIRA post, happens if we try to load any data ( fetching for lazy loaded collections for example ) without a trasaction started.
> We have looke at this extensively and ended up with having to have the OpenSessionInView filter open a transaction, just to make sure one exists, then when we call the service layer another stransaction is started ( which we belive is overkill, but works as a stop gap measure)
> We belive we should be able to fetch the data (READ ONLY) for lazy loaded collections without explicitly starting a trasaction.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[Hibernate-JIRA] Updated: (HHH-891) SET CHAINED command not allowed within multi-statement transaction
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-891?page=co... ]
Steve Ebersole updated HHH-891:
-------------------------------
Comment: was deleted
(was: Look [here | http://retractable-dog-leashes.net/small-dog-harnesses.html])
> SET CHAINED command not allowed within multi-statement transaction
> ------------------------------------------------------------------
>
> Key: HHH-891
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-891
> Project: Hibernate Core
> Issue Type: Bug
> Environment: Sybase 12.5, IBM Rational Application developer and WAS 6.0, Windows XP development stations. We'reusing latest verions of Spring. The JDBC Driver is JConnect 5.5
> Reporter: Harry Grongstad
> Priority: Blocker
>
> We are using the OpenSessionInView filter to open the Hibernate session, we call a service layer to load *most* data and that layer has transactional methods ( findXXX() ). The OpenSessionInView implementation we use starts a transaction (JTA). The service layer uses "REQUIRES NEW" as trasnaction attribute.
> The problem "ERROR JDBCExceptionReporter:58 - SET CHAINED command not allowed within multi-statement transaction" which was reported before in another JIRA post, happens if we try to load any data ( fetching for lazy loaded collections for example ) without a trasaction started.
> We have looke at this extensively and ended up with having to have the OpenSessionInView filter open a transaction, just to make sure one exists, then when we call the service layer another stransaction is started ( which we belive is overkill, but works as a stop gap measure)
> We belive we should be able to fetch the data (READ ONLY) for lazy loaded collections without explicitly starting a trasaction.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[Hibernate-JIRA] Closed: (HHH-891) SET CHAINED command not allowed within multi-statement transaction
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-891?page=co... ]
Steve Ebersole closed HHH-891.
------------------------------
Resolution: Rejected
> SET CHAINED command not allowed within multi-statement transaction
> ------------------------------------------------------------------
>
> Key: HHH-891
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-891
> Project: Hibernate Core
> Issue Type: Bug
> Environment: Sybase 12.5, IBM Rational Application developer and WAS 6.0, Windows XP development stations. We'reusing latest verions of Spring. The JDBC Driver is JConnect 5.5
> Reporter: Harry Grongstad
> Priority: Blocker
>
> We are using the OpenSessionInView filter to open the Hibernate session, we call a service layer to load *most* data and that layer has transactional methods ( findXXX() ). The OpenSessionInView implementation we use starts a transaction (JTA). The service layer uses "REQUIRES NEW" as trasnaction attribute.
> The problem "ERROR JDBCExceptionReporter:58 - SET CHAINED command not allowed within multi-statement transaction" which was reported before in another JIRA post, happens if we try to load any data ( fetching for lazy loaded collections for example ) without a trasaction started.
> We have looke at this extensively and ended up with having to have the OpenSessionInView filter open a transaction, just to make sure one exists, then when we call the service layer another stransaction is started ( which we belive is overkill, but works as a stop gap measure)
> We belive we should be able to fetch the data (READ ONLY) for lazy loaded collections without explicitly starting a trasaction.
--
This message is automatically generated by JIRA.
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] Commented: (HHH-891) SET CHAINED command not allowed within multi-statement transaction
by Fyrn Jilot (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-891?page=co... ]
Fyrn Jilot commented on HHH-891:
--------------------------------
Look [here | http://retractable-dog-leashes.net/small-dog-harnesses.html]
> SET CHAINED command not allowed within multi-statement transaction
> ------------------------------------------------------------------
>
> Key: HHH-891
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-891
> Project: Hibernate Core
> Issue Type: Bug
> Environment: Sybase 12.5, IBM Rational Application developer and WAS 6.0, Windows XP development stations. We'reusing latest verions of Spring. The JDBC Driver is JConnect 5.5
> Reporter: Harry Grongstad
> Priority: Blocker
>
> We are using the OpenSessionInView filter to open the Hibernate session, we call a service layer to load *most* data and that layer has transactional methods ( findXXX() ). The OpenSessionInView implementation we use starts a transaction (JTA). The service layer uses "REQUIRES NEW" as trasnaction attribute.
> The problem "ERROR JDBCExceptionReporter:58 - SET CHAINED command not allowed within multi-statement transaction" which was reported before in another JIRA post, happens if we try to load any data ( fetching for lazy loaded collections for example ) without a trasaction started.
> We have looke at this extensively and ended up with having to have the OpenSessionInView filter open a transaction, just to make sure one exists, then when we call the service layer another stransaction is started ( which we belive is overkill, but works as a stop gap measure)
> We belive we should be able to fetch the data (READ ONLY) for lazy loaded collections without explicitly starting a trasaction.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months