[Hibernate-JIRA] Created: (HHH-2098) Problem deleting entities in hierarchy
by Philippe Larouche (JIRA)
Problem deleting entities in hierarchy
--------------------------------------
Key: HHH-2098
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2098
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.2.0.cr3
Environment: Hibernate 3.2.0CR3 and Hibernate 3.2.0CR4, on an Oracle DB
Reporter: Philippe Larouche
Priority: Blocker
Hi, I'm using Hibernate 3.2.0 CR3 (also tried it with 3.2.0CR4) and when I try to delete entities in batch (with an HQL query), I got an error in the SQL translation of my query. I try to delete an entity that is the child of another one. Here are my mapping files:
Scancode (parent entity)......
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="com.cardinal.dal.entity.foundation.ScanCode" table="SCAN_CD_VW" schema="CDM_FND_1_0">
<composite-id name="id" class="com.cardinal.dal.entity.generated.foundation.ScanCodeId">
<key-property name="scanCdGuid" type="binary">
<meta attribute="use-in-equals" inherit="false">true</meta>
<column name="SCAN_CD_GUID"/>
</key-property>
<key-property name="operatingCntxGuid" type="binary">
<meta attribute="use-in-equals" inherit="false">true</meta>
<column name="OPERATING_CNTX_GUID"/>
</key-property>
</composite-id>
<version name="versionNum" column="VERSION_NUM" generated="always" unsaved-value="negative" insert="false"/>
<property name="dataDomainGuid" type="binary">
<column name="DATA_DOMAIN_GUID" not-null="true"/>
</property>
<property name="scanCdCls" type="string">
<column name="SCAN_CD_CLS" length="1" not-null="true"/>
</property>
<property name="scanCdTxt" type="string">
<column name="SCAN_CD_TXT" not-null="true"/>
</property>
<filter name="operatingCntxFilter" condition=":operatingCntxGuid = OPERATING_CNTX_GUID"/>
</class>
</hibernate-mapping>
PatientScancode (child entity).............
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<joined-subclass name="com.cardinal.dal.entity.patient.PatientScanCode" extends="com.cardinal.dal.entity.foundation.ScanCode" table="PATIENT_SCAN_CD_VW" schema="CDM_PAT_1_0">
<key>
<column name="PATIENT_SCAN_CD_GUID"/>
<column name="OPERATING_CNTX_GUID"/>
</key>
<property name="patientGuid" type="binary">
<meta attribute="scope-get" inherit="false">protected</meta>
<meta attribute="scope-set" inherit="false">protected</meta>
<column name="PATIENT_GUID"/>
</property>
<many-to-one name="patientVw" class="com.cardinal.dal.entity.patient.Patient" update="false" insert="false" fetch="select">
<column name="PATIENT_GUID" not-null="true"/>
<column name="OPERATING_CNTX_GUID"/>
</many-to-one>
</joined-subclass>
</hibernate-mapping>
Here's how I execute my delete statement in my session bean:
String queryStr = "delete from PatientScanCode as scancode " +
"where scancode.patientVw.id.partyGuid = ? ";
Query query = session.createQuery(queryStr);
query.setParameter(0, patientId.getPartyGuid());
query.executeUpdate();
I know that the query syntax is correct, the problem comes from the SQL translation made by Hibernate, here's what it looks like:
delete
from
CDM_PAT_1_0.PATIENT_SCAN_CD_VW
where
(
PATIENT_SCAN_CD_GUID, OPERATING_CNTX_GUID
) IN (
select
PATIENT_SCAN_CD_GUID,
OPERATING_CNTX_GUID
from
HT_PATIENT_SCAN_CD_VW
)
delete
from
CDM_FND_1_0.SCAN_CD_VW
where
(
SCAN_CD_GUID, OPERATING_CNTX_GUID
) IN (
select
PATIENT_SCAN_CD_GUID,
OPERATING_CNTX_GUID
from
HT_PATIENT_SCAN_CD_VW
)
There are 2 delete statements since it has to delete both the child and the parent. In the from clause in the select statement, the table called HT_PATIENT_SCAN_CD_VW is used, but it doesn't exist in our model. I suppose it should be a temporary table created by hibernate to keep in memory which rows have to be deleted when it's time to delete the parent table. The problem is that this table doesn't seem to be created properly before running delete statements cause I get the following exception when it is called on the database:
19:04:06,001 ERROR [JDBCExceptionReporter] ORA-00918: column ambiguously defined
19:04:06,017 WARN [MultiTableDeleteExecutor] unable to cleanup temporary id table after use
java.sql.SQLException: ORA-00942: table or view does not exist
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.hibernate.hql.ast.exec.AbstractStatementExecutor.dropTemporaryTableIfNecessary(AbstractStatementExecutor.java:179)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:136)
at org.hibernate.hql.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:391)
at org.hibernate.engine.query.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:259)
at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:1134)
at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:94)
at com.cardinal.dal.session.patient.PatientScanCodeBean.deleteAllByPatient(PatientScanCodeBean.java:75)
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:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:181)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
at $Proxy866.deleteAllByPatient(Unknown Source)
at testng.com.cardinal.dal.session.patient.PatientScanCodeTestBean.deleteAllByPatient(PatientScanCodeTestBean.java:101)
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:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:225)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
19:04:06,095 ERROR [PatientScanCodeBean] Error in com.cardinal.dal.session.patient.PatientScanCodeBean.invoke0(): org.hibernate.exception.SQLGrammarException: could not insert/select ids for bulk delete
org.hibernate.exception.SQLGrammarException: could not insert/select ids for bulk delete
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:102)
at org.hibernate.hql.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:391)
at org.hibernate.engine.query.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:259)
at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:1134)
at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:94)
at com.cardinal.dal.session.patient.PatientScanCodeBean.deleteAllByPatient(PatientScanCodeBean.java:75)
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:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:181)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
at $Proxy866.deleteAllByPatient(Unknown Source)
at testng.com.cardinal.dal.session.patient.PatientScanCodeTestBean.deleteAllByPatient(PatientScanCodeTestBean.java:101)
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:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:225)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
Caused by: java.sql.SQLException: ORA-00918: column ambiguously defined
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:93)
... 67 more
Thx to keep me posted on this one
Phil
--
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
18 years, 9 months
[Hibernate-JIRA] Created: (HHH-2812) DELETE hql statement generating bad SQL on postgres 8.2
by Joseph Marques (JIRA)
DELETE hql statement generating bad SQL on postgres 8.2
-------------------------------------------------------
Key: HHH-2812
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2812
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.3
Environment: JBoss [Trinity] 4.2.0.GA (build: SVNTag=JBoss_4_2_0_GA date=200705111440)
Reporter: Joseph Marques
Here's is an object model:
class Alert {
int id;
...
AlertDefinition alertDefinition;
...
}
class AlertDefinition {
int id;
...
Resource resource;
...
}
class Resource {
int id;
...
}
Here is some incredibly simple hql:
DELETE Alert AS alert
WHERE alert.alertDefinition.resource.id = 0
And this is what it translates to on postgres:
DELETE
FROM alert, alert_definition
WHERE resource_id=0
Unless a user knows that this doesn't translate correctly, this is the error they will get when they try to execute it:
WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 42601
ERROR [JDBCExceptionReporter] ERROR: syntax error at or near ","
ERROR ... javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute update query
Though postgres does support this...in an albeit awkward form. You can only select from a single table, but you can use a list of "related" tables (http://www.postgresql.org/docs/8.1/static/sql-delete.html). So, it should have looked something like:
DELETE
FROM alert
USING alert_definition
WHERE resource_id=0
As the documentation specifies, it's possible to use a more common sub-select syntax like:
DELETE FROM alert
WHERE id IN
(
SELECT alert1.id
FROM alert a1, alert_definition ad1
WHERE a1.alert_definition_id = ad1.id
AND ad1.resource_id = 0
)
And here's the corresponding hql that I ended up using to achieve this:
DELETE Alert AS a
WHERE a.id IN
(
SELECT ia.id
FROM Alert ia
WHERE ia.alertDefinition.resource.id = 0
)
However, I still think the query translator should support the join syntax instead of forcing the sub-select syntax.
--
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
18 years, 9 months
[Hibernate-JIRA] Created: (HHH-2149) Wrong SQL generated with delete HQL
by jeremie balcaen (JIRA)
Wrong SQL generated with delete HQL
-----------------------------------
Key: HHH-2149
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2149
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.1.3
Environment: Hibernate version 3.1.3
oracle version 9
Reporter: jeremie balcaen
Priority: Minor
Here is the delete HQL statement :
delete Label label where label.numseq = '01' and label.codlan = '01'" and label.mytad.argtbl = 'BE' and label.mytad.numbtl = '054'
The generated SQL is :
delete from JPRG.LABEL, MYTAD mytad1_ where NUMSEQ='01' and CODLAN='01' and ARGTBL='BE' and NUMBTL='054'
Here are the mapping files :
<hibernate-mapping package="com.cwsoft.businessobject">
<class name="Label" table="LABEL" >
<composite-id>
<key-many-to-one name="mytad">
<column name="NUMBTL"/>
<column name="ARGTBL"/>
</key-many-to-one>
<key-property name="numseq" type="string">
<column name="NUMSEQ"/>
</key-property>
<key-property name="codlan" type="string">
<column name="CODLAN"/>
</key-property>
</composite-id>
<property name="labele" column="LABELE" type="string" not-null="true" />
</class>
</hibernate-mapping>
The associated class is defined with a composite-id : (with id, it works fine)
<hibernate-mapping package="com.cwsoft.businessobject">
<class name="Mytad" table="MYTAD">
<composite-id>
<key-property name="numbtl" type="string">
<column name="NUMBTL"/>
</key-property>
<key-property name="argtbl" type="string">
<column name="ARGTBL"/>
</key-property>
</composite-id>
<property name="thdesc" type="string" column="THDESC"/>
</class>
</hibernate-mapping>
--
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
18 years, 9 months
[Hibernate-JIRA] Created: (HBX-965) conditionally exclude catalog in H2MetaDataDialect
by Dan Allen (JIRA)
conditionally exclude catalog in H2MetaDataDialect
--------------------------------------------------
Key: HBX-965
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-965
Project: Hibernate Tools
Issue Type: Improvement
Components: reverse-engineer
Affects Versions: 3.2beta10
Environment: H2 1.0 (2007-06-17) and H2 1.0 (2007-07-12)
Reporter: Dan Allen
Priority: Minor
Prior to build 55 (aka version 1.0 2007-07-12), the H2 database did not understand a query that included the catalog name. For instance, if you had a table called EMPLOYEE in the PUBLIC schema, H2.PUBLIC.EMPLOYEE would not work. After build 55, H2 understands this query.
However, this brings up a different issue. You cannot create catalogs in H2, so really the H2 catalog is just a bogus place holder. That has to make you wonder if putting the catalog in the reverse engineering dialect is even wise. It makes the hbm2java generated classes very non-portable. This debate is a bit of a fuzzy area for me.
--
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
18 years, 9 months
[Hibernate-JIRA] Created: (HHH-2598) Mapping a collection of entities from two different classes with the same collection name results in duplicate backref property exception if collection keys are not null
by Guido Scalise (JIRA)
Mapping a collection of entities from two different classes with the same collection name results in duplicate backref property exception if collection keys are not null
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2598
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2598
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.2, 3.2.1
Environment: Proven on Hibernate 3.2.2 and 3.2.3, PostgreSQL 8.2.3, WindowsXP, Java 1.5
Reporter: Guido Scalise
Attachments: backref.patch, Hibernate-bug.zip
Mapping a child entity collection from two different parent entities results in duplicate backref property exception when configuring the session factory if the collection keys are marked not null and the collection names are the same in both parents.
Log is:
(cfg.Environment 509 ) Hibernate 3.2.3
(cfg.Environment 542 ) hibernate.properties not found
(cfg.Environment 676 ) Bytecode provider name : cglib
(cfg.Environment 593 ) using JDK 1.4 java.sql.Timestamp handling
(cfg.Configuration 1426) configuring from resource: /hibernate.cfg.xml
(cfg.Configuration 1403) Configuration resource: /hibernate.cfg.xml
(cfg.Configuration 553 ) Reading mappings from resource : com/bbsw/tests/ParentA.hbm.xml
(cfg.HbmBinder 300 ) Mapping class: com.bbsw.tests.ParentA -> PARENT_A
(cfg.Configuration 553 ) Reading mappings from resource : com/bbsw/tests/ParentB.hbm.xml
(cfg.HbmBinder 300 ) Mapping class: com.bbsw.tests.ParentB -> PARENT_B
(cfg.Configuration 553 ) Reading mappings from resource : com/bbsw/tests/Child.hbm.xml
(cfg.HbmBinder 300 ) Mapping class: com.bbsw.tests.Child -> CHILD
(cfg.Configuration 1541) Configured SessionFactory: null
(cfg.HbmBinder 2375) Mapping collection: com.bbsw.tests.ParentA.children -> CHILD
(cfg.HbmBinder 2375) Mapping collection: com.bbsw.tests.ParentB.children -> CHILD
Exception in thread "main" org.hibernate.MappingException: Duplicate property mapping of _childrenBackref found in com.bbsw.tests.Child
at org.hibernate.mapping.PersistentClass.checkPropertyDuplication(PersistentClass.java:459)
at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:449)
at org.hibernate.mapping.RootClass.validate(RootClass.java:192)
at org.hibernate.cfg.Configuration.validate(Configuration.java:1102)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1287)
at HBTest.main(HBTest.java:17)
The problem seems to be originated during the second Collection binding pass in org.hibernate.cfg.HbmBinder, as the Backrefs and IndexBackrefs names are created like this:
(Excerpts from HbmBinder.java r10921 2006-12-05 14:39:12Z steve.ebersole(a)jboss.com, contained in the Hibernate 3.2.3.ga source)
line 2242: IndexBackref ib = new IndexBackref();
line 2243: ib.setName( '_' + node.attributeValue( "name" ) + "IndexBackref" );
and
line 2478: Backref prop = new Backref();
line 2479: prop.setName( '_' + node.attributeValue( "name" ) + "Backref" );
in both cases the node name value is the collection name. So for every collection that points to a child, Hibernate creates a backref property without considering the posibility of more than one entity declaring the same collection name.
I've patched the code to add the collection owner's entity name to the property name, and it worked without problems.
I'm attaching:
* ParentA, ParentB and Child classes
* Mappings for ParentA, ParentB and Child
* hbm.xml file
* Main test case. (HBTest.java)
* Proposed patch in unified diff format.
--
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
18 years, 10 months
[Hibernate-JIRA] Created: (HHH-2734) PreparedStatement leak with lazy properties
by Christian Gruber (JIRA)
PreparedStatement leak with lazy properties
-------------------------------------------
Key: HHH-2734
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2734
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: Hibernate 3.2.4
Oracle 10g
Sun Java 1.5.0
Reporter: Christian Gruber
Priority: Critical
Hello!
When iterating through more than 300 elements that have lazy properties, I get an ORA-01000 JDBC error ("maximum open cursors exceeded"). I found out that the root cause for this are unclosed prepared statements in AbstractBatcher.prepareSelectStatement(String). When I add the generated prepared statement to the statementsToClose set in this method, the problem vanishes. But I don't have an idea what other effects this might have, and why the prepared statement was not added to the statements to close in the first place.
How to reproduce:
- Make a class with at least one lazy property; instrument the byte code
- Create an Oracle database with at least 300 entries in the table for this class
- Execute the following code:
Iterator<MyClass> it = session.createQuery("from MyClass mc").iterate();
while (it.hasNext()) {
MyClass mc = it.next();
String la = mc.getLazyAttribute();
session.evict(mc);
}
- Watch the log for org.hibernate.jdbc.AbstractBatcher entries containing
"about to open ResultSet" and see the numbers increase
As already mentioned, a simple fix for this is adding "statementsToClose.add( ps );" into AbstractBatcher.java, around line 133 (assigning the PreparedStatement to a new variable "ps" first, of course), but as I don't understand the differences between the various PreparedStatement generating methods there, that might give rise to other problems.
Thanks for looking at it,
Christian
--
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
18 years, 10 months
[Hibernate-JIRA] Created: (HHH-2867) HIbernate reflection optimization with javassist MUCH slower than in previous versions with cglib
by MG (JIRA)
HIbernate reflection optimization with javassist MUCH slower than in previous versions with cglib
-------------------------------------------------------------------------------------------------
Key: HHH-2867
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2867
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Reporter: MG
Hibernate reflection optimization with javassist MUCH slower than in previous versions with cglib,
and there is no way to set it to use cglib anymore
I'm setting
hibernate.bytecode.provider=cglib
in hibernate.properties
but it is still using javassist
[java] 10:42:00,675 INFO [Version] Hibernate Annotations 3.2.1.GA
[java] 10:42:00,722 INFO [Environment] Hibernate 3.2.3
[java] 10:42:00,737 INFO [Environment] loaded properties from resource hibernate.properties: {hibernate.jdbc.use_streams_for_binary=fal
se, hibernate.bytecode.use_reflection_optimizer=true, hibernate.bytecode.provider=cglib}
[java] 10:42:00,737 INFO [Environment] using bytecode reflection optimizer
[java] 10:42:00,737 INFO [Environment] Bytecode provider name : javassist
[java] 10:42:00,753 INFO [Environment] using JDK 1.4 java.sql.Timestamp handling
Please, check sample code in
http://jira.jboss.com/jira/browse/JBSEAM-1977
which compares cglib with javassist optimizations
cglib beats JDK 5 reflection almost 10 times
javassist performs even slower than JDK 5 reflection
--
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
18 years, 10 months