[Hibernate-JIRA] Created: (HHH-6777) HQL "in" transformed to incorrect SQL with Oracle dialect
by Michael Zeising (JIRA)
HQL "in" transformed to incorrect SQL with Oracle dialect
---------------------------------------------------------
Key: HHH-6777
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6777
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 4.0.0.Beta5
Environment: JBoss AS 7.0.1.Final, Hibernate Core 4.0.0.Beta5, Oracle 10g
Reporter: Michael Zeising
Priority: Critical
The HQL query
{{select c.left_id, c.right_id from Allocation_Conflict c where c.planning_id = :planningId and ((c.left_id in :allocationIds) or (c.right_id in :allocationIds))}}
is translated to
{{... (c.left_id in ?, ?) or (c.right_id in ?, ?)}}
which leads to the Oracle error "ORA-00907: missing right parenthesis". The workaround is to write
{{... ((c.left_id in (:allocationIds)) or (c.right_id in (:allocationIds)))}}
which is not intented because Hibernate adds the parenthesis automatically in other queries.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6779) ByteType mapped to tinyint, but on sybase/ms sql server, tinyint is unsigned int
by Strong Liu (JIRA)
ByteType mapped to tinyint, but on sybase/ms sql server, tinyint is unsigned int
--------------------------------------------------------------------------------
Key: HHH-6779
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6779
Project: Hibernate Core
Issue Type: Bug
Components: core
Environment: sybase, sql server
Reporter: Strong Liu
ByteType maps tinyint and byte
which byte on java is [-128,127]
but on sybase / sql server, the tinyint scope is [0-128)
this causes org.hibernate.test.typedescriptor.ByteTest fail, stace trace is same as HHH-3679
change the mapping of tinyint to number(3,0) in org.hibernate.dialect.AbstractTransactSQLDialect would fix this issue
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6555) IdClass and mappedBy problem
by Piotr Gliźniewicz (JIRA)
IdClass and mappedBy problem
----------------------------
Key: HHH-6555
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6555
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 4.0.0.Beta4, 3.6.6, 4.0.0.Beta2
Environment: Derby 10.8.1.2
Reporter: Piotr Gliźniewicz
I have the following classes:
{code}@Entity
public class SimpleEntity {
@Id
private int id;
@OneToOne(cascade = CascadeType.ALL, mappedBy = "entityA")
private EntityConnection connection;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "entityB")
private List<EntityConnection> otherConnections;
// accessors
}{code}
{code}@Entity
@IdClass(EntityConnectionPK.class)
public class EntityConnection {
@Id
@JoinColumn(name = "entity_a_id")
@OneToOne
private SimpleEntity entityA;
@Id
@JoinColumn(name = "entity_b_id")
@ManyToOne
private SimpleEntity entityB;
// accessors
}{code}
{code}public class EntityConnectionPK implements Serializable {
private int entityA;
private int entityB;
// accessors, equals, hashcode
}{code}
Executing the following query:
{code}
TypedQuery<SimpleEntity> q = em.createQuery("select e from SimpleEntity e where e.id = 1", SimpleEntity.class);
SimpleEntity foundEntity = q.getResultList().get(0);
{code}
results in:
{code}Exception in thread "main" java.lang.NullPointerException
at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:2200)
at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:661)
at org.hibernate.type.EntityType.resolve(EntityType.java:441)
at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:150)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1012)
at org.hibernate.loader.Loader.doQuery(Loader.java:889)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:289)
at org.hibernate.loader.Loader.doList(Loader.java:2449)
at org.hibernate.loader.Loader.doList(Loader.java:2435)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
at org.hibernate.loader.Loader.list(Loader.java:2271)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:470)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:355)
at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1105)
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:100)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:252){code}
After some debugging I found that Hibernate ignores the mappedBy values and uses names with prepended "_identifierMapper". After changing the annotations to:
{code}@Entity
public class SimpleEntity {
@Id
private int id;
@OneToOne(cascade = CascadeType.ALL, mappedBy = "_identifierMapper.entityA")
private EntityConnection connection;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "_identifierMapper.entityB")
private List<EntityConnection> otherConnections;
// accessors
}{/code}
the code works.
Expected: the first example of SimpleEntity should work.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-3410) @OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false)
by Kamil Morong (JIRA)
@OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false)
----------------------------------------------------------------------------------------------
Key: HHH-3410
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3410
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: MySQL 5.0.51b, Hibernate Core 3.2.6 GA, Hibernate Annotations 3.3.1 GA
Reporter: Kamil Morong
Hi,
I need to have this class composition with one to many relation:
@Entity
@Table(name="USER")
public class User implements java.io.Serializable {
private Long id;
private String username;
private String password;
private Set<Role> roles = new LinkedHashSet<Role>();
public User() {
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "USER_ID")
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@Column(name="USERNAME", nullable=false, unique=true)
public String getUsername() {
return username;
}
public void setUsername(String userName) {
this.username = userName;
}
@Column(name="PASSWORD", nullable=false)
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
@CollectionOfElements
@OneToMany(cascade={CascadeType.PERSIST, CascadeType.MERGE})
@JoinTable(name = "USER_ROLE",
joinColumns = @JoinColumn(name = "USER_ID", unique=false),
inverseJoinColumns = @JoinColumn(name = "ROLE_ID", unique=false))
@Cascade(org.hibernate.annotations.CascadeType.SAVE_UPDATE)
@LazyCollection(LazyCollectionOption.FALSE)
public Set<Role> getRoles() {
return roles;
}
public void setRoles(Set<Role> roles) {
this.roles = roles;
}
}
@Entity
@Table(name="ROLE")
public class Role implements java.io.Serializable {
private Long id;
private String name;
public Role() {
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "ROLE_ID")
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@Column(name="NAME", nullable=false, unique=true)
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
This will create db tables like SQL script
CREATE TABLE `user` (
`USER_ID` BIGINT(20) NOT NULL AUTO_INCREMENT,
`PASSWORD` VARCHAR(255) NOT NULL DEFAULT '',
`USERNAME` VARCHAR(255) NOT NULL DEFAULT '',
PRIMARY KEY (`USER_ID`),
UNIQUE KEY `USERNAME` (`USERNAME`)
);
CREATE TABLE `role` (
`ROLE_ID` BIGINT(20) NOT NULL AUTO_INCREMENT,
`NAME` VARCHAR(255) NOT NULL DEFAULT '',
PRIMARY KEY (`ROLE_ID`),
UNIQUE KEY `NAME` (`NAME`)
);
CREATE TABLE `user_role` (
`USER_ID` BIGINT(20) NOT NULL,
`ROLE_ID` BIGINT(20) NOT NULL,
PRIMARY KEY (`USER_ID`, `ROLE_ID`),
UNIQUE KEY `ROLE_ID` (`ROLE_ID`),
KEY `FKBC16F46A1174FFAB` (`ROLE_ID`),
KEY `FKBC16F46AB69FC38B` (`USER_ID`),
CONSTRAINT `FKBC16F46AB69FC38B` FOREIGN KEY (`USER_ID`) REFERENCES `user` (`USER_ID`),
CONSTRAINT `FKBC16F46A1174FFAB` FOREIGN KEY (`ROLE_ID`) REFERENCES `role` (`ROLE_ID`)
);
Tables USER and ROLE are right, but the join table USER_ROLE still have defined UNIQUE KEY `ROLE_ID` (`ROLE_ID`).
This causes there cannot be one user with many roles.
There must be some bug while generating database scheme. I am not able to remove unique key.
--
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
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-3716) Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL
by Gail Badner (JIRA)
Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL
----------------------------------------------------------------------------------------------
Key: HHH-3716
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3716
Project: Hibernate Core
Issue Type: Bug
Components: core
Environment: Sybase
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.2.x, 3.3.x, 3.4
Null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL. This happens because Hibernate persists a null Boolean value by calling:
PreparedStatement.setNull( index, java.sql.Types.BIT )
The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT.
Sybase JDBC converts the null to 0, apparently because Sybase does not allow nullable bit columns.
This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing()..
Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null.
I've verified that changing the call to:
PreparedStatement.setNull( index, java.sql.Types.TINYINT )
persists the null value without being converted to 0.
--
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
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-5413) null values for columns mapped as "boolean" cause exception when saving entity with Sybase jdbc4
by Strong Liu (JIRA)
null values for columns mapped as "boolean" cause exception when saving entity with Sybase jdbc4
------------------------------------------------------------------------------------------------
Key: HHH-5413
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5413
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0.Beta1, 3.5.4, 3.5.3
Environment: Sybase jdbc4
Reporter: Strong Liu
ASE doesn't allow 'null' value for 'BIT' datatype;
While performing insert operation using jconn3.jar it permit you to have
'null' value, this 'null' value is converted into bit 0 by jconn3 & hence
ASE doesn't throw any exception;
But incase of jconn4.jar 'null' value is not converted into bit 0, hence
jconn4 directly reports an exception for 'null' value(which is the expected
correct behavior)
Hibernate persists a null Boolean value by calling:
PreparedStatement.setNull( index, java.sql.Types.BIT )
The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT.
This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing()..
Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null.
I've verified that changing the call to:
PreparedStatement.setNull( index, java.sql.Types.TINYINT )
persists the null value without being converted to 0.
--
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
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6743) Hibernate caches connection, causing sharding failure
by Matthew Adams (JIRA)
Hibernate caches connection, causing sharding failure
-----------------------------------------------------
Key: HHH-6743
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6743
Project: Hibernate Core
Issue Type: Bug
Components: core, entity-manager
Affects Versions: 3.6.7
Environment: hibernate-entitymanager 3.6.7.Final, derby 10.8.1.2, spring-orm 3.1.0.RC1
Reporter: Matthew Adams
Attachments: shard-test-example.zip
It appears as though Hibernate is caching a database connection, which causes my portable sharding solution to fail. The sharding solution uses Spring's AbstractRoutingDataSource to provide sharded connections to one of two underlying databases. DataNucleus 3.0.x & OpenJPA 2.1.x work fine.
Sample project with reproducible test case attached. After extracting zip, reproduce error by running "mvn clean test -P hib". To run DataNucleus, run "mvn clean test". To run OpenJPA, run "mvn clean test -P openjpa".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6454) Stafeful, no transaction and persist entity with generatedValue for ID : javax.transaction.InvalidTransactionException: Cannot resume foreign transaction: null
by pierre devreux (JIRA)
Stafeful, no transaction and persist entity with generatedValue for ID : javax.transaction.InvalidTransactionException: Cannot resume foreign transaction: null
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-6454
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6454
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.6.5, 3.6.3
Environment: OpenEJB 3.2.0,Java 6, Hibernate-entity-manager: 3.6.3, hibernate-validator:4.0.2.
Reporter: pierre devreux
Here my use case :
I have
* a _Service_ entity :
{code:title=Service.java|borderStyle=solid}
@Entity
@TableGenerator(name="ServiceGenerator", pkColumnName="pk_val", pkColumnValue= "service_id", valueColumnName="val",table= "IDENTIFIER")
public class Service {
@Id
@GeneratedValue(generator="ServiceGenerator", strategy=GenerationType.TABLE)
private long id;
private String name;
private String des;
public Service(){};
public Service(String name, String des) {
this.name = name;
this.des = des;
}
}
{code}
* a _ServiceSF / ServiceSFImpl_ stateful :
{code:title=ServiceSFImpl.java|borderStyle=solid}
@Stateful
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class ServiceSFImpl implements ServiceSF {
@PersistenceContext(name="unit", type=PersistenceContextType.EXTENDED)
EntityManager em;
public void persist(Service s) {
em.persist(s);
}
@Remove
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void remove() {
}
}
{code}
* a test
{code:title=Test.java|borderStyle=solid}
...
@Test
public void createServiceSF() throws NamingException {
ServiceSF sf = (ServiceSF) context.lookup("ServiceSFImplLocal");
Service s = new Service("name", desc");
sf.persist(s);
sf.remove();
}
...
{code}
When I launch it, persist method raise an exception : _javax.transaction.InvalidTransactionException: Cannot resume foreign transaction: null_ .
After looking the code, I saw that hibernate starts a new transaction to get the generated ID, and then resume the previous transaction. But in my case there is no transaction, and Hibernate throw an InvalidTransactionException.
Here the complete stack trace :
{code:title=Bar.java|borderStyle=solid}
javax.ejb.EJBException: The bean encountered a non-application exception; nested exception is:
javax.persistence.PersistenceException: org.hibernate.HibernateException: Unable to resume previously suspended transaction
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:359)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:287)
at $Proxy44.persist(Unknown Source)
at net.atos.od.td.nda.ddd.rt.jee.impl.DomainTransactionImpl.persist(DomainTransactionImpl.java:163)
at net.atos.ddd.test.LauncherTest.createService_aroundBody0(LauncherTest.java:39)
at net.atos.ddd.test.LauncherTest.createService_aroundBody1$advice(LauncherTest.java:31)
at net.atos.ddd.test.LauncherTest.createService(LauncherTest.java:1)
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.InvokeMethod.evaluate(InvokeMethod.java:20)
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.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
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:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
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)
Caused by: javax.persistence.PersistenceException: org.hibernate.HibernateException: Unable to resume previously suspended transaction
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1214)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1147)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1153)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:678)
at org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:114)
at net.atos.od.td.nda.ddd.rt.jee.impl.GatewayImpl.persist(GatewayImpl.java:39)
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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
at org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:164)
at org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:92)
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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:122)
at org.apache.openejb.core.stateful.StatefulContainer.businessMethod(StatefulContainer.java:566)
at org.apache.openejb.core.stateful.StatefulContainer.invoke(StatefulContainer.java:325)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:282)
... 32 more
Caused by: org.hibernate.HibernateException: Unable to resume previously suspended transaction
at org.hibernate.engine.transaction.Isolater$JtaDelegate.delegateWork(Isolater.java:147)
at org.hibernate.engine.transaction.Isolater.doIsolatedWork(Isolater.java:67)
at org.hibernate.engine.TransactionHelper.doWorkInNewTransaction(TransactionHelper.java:74)
at org.hibernate.id.MultipleHiLoPerTableGenerator$1.getNextValue(MultipleHiLoPerTableGenerator.java:216)
at org.hibernate.id.enhanced.OptimizerFactory$LegacyHiLoAlgorithmOptimizer.generate(OptimizerFactory.java:351)
at org.hibernate.id.MultipleHiLoPerTableGenerator.generate(MultipleHiLoPerTableGenerator.java:213)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:121)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:69)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:179)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:135)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:808)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:782)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:786)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:672)
... 54 more
Caused by: javax.transaction.InvalidTransactionException: Cannot resume foreign transaction: null
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.resume(TransactionManagerImpl.java:181)
at org.hibernate.engine.transaction.Isolater$JtaDelegate.delegateWork(Isolater.java:138)
... 68 more
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6697) EntityManager.persist should through EntityExistsException instead of PersistenceException
by Michael Rudolf (JIRA)
EntityManager.persist should through EntityExistsException instead of PersistenceException
------------------------------------------------------------------------------------------
Key: HHH-6697
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6697
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.6.7
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.5.0_22
Java home: C:\Program Files\Java\jdk1.5.0_22\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
Reporter: Michael Rudolf
The persist method of the {{EntityManager}} interface is not implemented according to the specification. If handed an already existing entity, it throws an instance of {{PersistenceException}} instead of {{EntityExistsException}}. The fact that the exception's cause is an instance of {{DuplicateEntityException}} does not help clients to determine the reason for the failure in a vendor-independent fashion. Changing this behavior will most likely not break existing clients, because they often catch instances of {{PersistenceException}}, which will also catch {{EntityExistsException}} instances. However, it will enable clients to detect the reason for the failure and thereby allow for better error reporting to the user. In fact, in case no transaction is running while this call fails, clients can also recover from the failure and queued actions can be committed afterwards.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6730) Query#setParameterList silently overwrites previous parameters
by Alexander Keul (JIRA)
Query#setParameterList silently overwrites previous parameters
--------------------------------------------------------------
Key: HHH-6730
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6730
Project: Hibernate Core
Issue Type: Improvement
Components: query-hql, query-sql
Affects Versions: 3.6.6
Reporter: Alexander Keul
Priority: Minor
When setting a parameter list on a query Hibernate's expandParameterList silently overwrites existing parameters.It requires a very specific set of conditions to be an issue, but I believe Hibernate should at least throw an exception rather than continuing on it's merry way. The issue is specifically found at the end of the function, line 789-796 in 3.6.2.FINAL. Hibernate aliases the expanded parameterlist based on the original name (:param0 -> :param00_, :param01_, etc), which can cause issues if
1) The parameters are themselves sublists, or are for some other reason named with numbers at the end
and
2) The parameter lists contain at least 10 items.
For example
:param1 expands to :param110_ (11th element)
:param11 expands to :param 110_ (1st element)
The problem could be avoided by changing the name expansion into
while ( iter.hasNext() ) {
String alias = ( isJpaPositionalParam ? 'x' + name : name ) + i++ + '_';
Object oldVal = namedParamsCopy.put( alias, new TypedValue( type, iter.next(), session.getEntityMode() ) );
if ( oldVal != null ) {
throw new QueryException("Named parameterlist " + name + " expands into an ambiguous parameter");
}
list.append( ParserHelper.HQL_VARIABLE_PREFIX ).append( alias );
if ( iter.hasNext() ) {
list.append( ", " );
}
}
No patch or testcast attached at this time, but if one's requested I can see if I can't get one up reasonably soon.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months