[Hibernate-JIRA] Created: (HHH-2791) HQL not cascading 'all-delete-orphan'
by venkata sankara (JIRA)
HQL not cascading 'all-delete-orphan'
-------------------------------------
Key: HHH-2791
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2791
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.1.3
Environment: Windows, HSQL-DB, Eclipse, HBMs, POJOs (No annotations)
Reporter: venkata sankara
Priority: Critical
Attachments: HibernateParentChildTest.zip
I have a classes i) Parent and ii) Child.
Both have only one field: String id;
Parent has been configured for one-to-many relationship with Child.
Entry in HBM:
<set name="children" lazy="true" inverse="true" cascade="all-delete-orphan" >
<key column="parent" />
<one-to-many class="model.Child" />
</set>
The following HQL doesn't cascade deletes:
delete Parent p where p.id = :parentId
However, the following code cascades deletes:
Parent p = session.get(Parent, "1");
session.delete(parent);
I have attached my eclipse project also. It is a small one with hardly 5 files.
--
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
17 years, 5 months
[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Steve Ebersole commented on HHH-1786:
-------------------------------------
Reggie, since you are "in bed" with IBM in this way, perhaps you'd be willing to look at the feasibility of HHH-2703 as well?
Funny how such transactionality is magically available from IBM once someone payed them money, but not when IBM customers/partners who are also Hibernate users asked about it (these are the same versions of WAS correct?).
> JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
> ------------------------------------------------------------------------------
>
> Key: HHH-1786
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786
> Project: Hibernate3
> Issue Type: Improvement
> Affects Versions: 3.1.2
> Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24
> Reporter: Tomi Szabo
> Assignee: Steve Ebersole
> Fix For: 3.3
>
> Attachments: JTASessionContext.java, WebSphereExtendedJTATransactionLookup.java, WebSphereExtendedJTATransactionLookup.patch.txt
>
>
> We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext.
> Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map.
> Possible patch is in attachements.
--
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
17 years, 5 months
[Hibernate-JIRA] Updated: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Steve Ebersole updated HHH-1786:
--------------------------------
Assignee: Steve Ebersole
Fix Version/s: 3.3
> JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
> ------------------------------------------------------------------------------
>
> Key: HHH-1786
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786
> Project: Hibernate3
> Issue Type: Improvement
> Affects Versions: 3.1.2
> Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24
> Reporter: Tomi Szabo
> Assignee: Steve Ebersole
> Fix For: 3.3
>
> Attachments: JTASessionContext.java, WebSphereExtendedJTATransactionLookup.java, WebSphereExtendedJTATransactionLookup.patch.txt
>
>
> We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext.
> Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map.
> Possible patch is in attachements.
--
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
17 years, 5 months
[Hibernate-JIRA] Commented: (HHH-1524) Error on left outer join with Oracle Dialect: ORA-00936: missing expression
by Diego Pires Plentz (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524?page=c... ]
Diego Pires Plentz commented on HHH-1524:
-----------------------------------------
HHH-2189 (dup) have more info.
> Error on left outer join with Oracle Dialect: ORA-00936: missing expression
> ---------------------------------------------------------------------------
>
> Key: HHH-1524
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524
> Project: Hibernate3
> Issue Type: Bug
> Components: query-sql
> Affects Versions: 3.1.2
> Environment: Oracle 8.1.7, Hibernate 3.1.2
> Reporter: Marcelo Oliveira
> Priority: Critical
> Attachments: HHH-1524.patch, ORA-00936.zip, SUP-3701.zip
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> With this HQL:
> from Company comp
> left outer join comp.employees empl
> with empl.birthday > :date
> Produce following SQL:
> select
> company0_.id as id0_0_,
> employees1_.id as id1_1_,
> company0_.companyName as companyN2_0_0_,
> employees1_.name as name1_1_,
> employees1_.birthday as birthday1_1_,
> employees1_.companyId as companyId1_1_
> from
> TB_COMPANY_TEMP company0_,
> TB_EMPLOYEE_TEMP employees1_
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>(+)=?)
> When it is run, the stacktrace is:
> org.hibernate.exception.SQLGrammarException: could not execute query
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:65)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2148)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
> at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
> at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1129)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at mytest.OuterJoinTest.main(OuterJoinTest.java:28)
> Caused by: java.sql.SQLException: ORA-00936: missing expression
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1870)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:314)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2145)
> ... 8 more
> The correct where clause should be :
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>=?)
> This error don't occur with MySQLDialect or SQLServerDialect. Probably it considers >= as two operators instead of a single operator.
--
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
17 years, 5 months
[Hibernate-JIRA] Created: (HHH-2189) Left Outer Join Conditions
by yann degat (JIRA)
Left Outer Join Conditions
--------------------------
Key: HHH-2189
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2189
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.1.3
Reporter: yann degat
Priority: Blocker
Attachments: OracleJoinFragment.java, OracleJoinFragment.java
the "org.hibernate.sql.OracleJoinFragment.addLeftOuterJoinCondition"
does not take the "!=" operator into account.
it places the "(+)" like this "!(+)=" instead of " (+) !="
( != is a valid operator for Oracle )
and it returns (+)<(+)> for the '<>' operator
here's a patch. (maybe not the best one )
/**
* This method is a bit of a hack, and assumes
* that the column on the "right" side of the
* join appears on the "left" side of the
* operator, which is extremely wierd if this
* was a normal join condition, but is natural
* for a filter.
*/
private void addLeftOuterJoinCondition(String on) {
StringBuffer buf = new StringBuffer( on );
for ( int i = 0; i < buf.length(); i++ ) {
char character = buf.charAt( i );
boolean isInsertPoint = OPERATORS.contains( new Character( character ) ) ||
( character == ' ' && buf.length() > i + 3 && "is ".equals( buf.substring( i + 1, i + 4 ) ) ) ;
if( character == '<' && buf.length() > i + 1 && ">".equals( buf.substring( i + 1, i + 2 ) ) ){
isInsertPoint = false;
buf.insert( i, "(+)" );
i += 3 + 2;
}
if ( isInsertPoint ) {
buf.insert( i, "(+)" );
i += 3;
}
if( character == '!' && buf.length() > i + 1 && "=".equals( buf.substring( i + 1, i + 2 ) ) ){
buf.insert( i, "(+)" );
i += 3 + 2;
}
}
addCondition( buf.toString() );
}
--
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
17 years, 5 months
[Hibernate-JIRA] Resolved: (HHH-1396) Table.validateColumns fails on valid column
by Diego Pires Plentz (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1396?page=c... ]
Diego Pires Plentz resolved HHH-1396.
-------------------------------------
Resolution: Fixed
Fix Version/s: 3.3
Closing as "fixed" since the main problem is solved and the "comment problem" is fixed by HHH-2315.
> Table.validateColumns fails on valid column
> -------------------------------------------
>
> Key: HHH-1396
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1396
> Project: Hibernate3
> Issue Type: Bug
> Components: metamodel
> Affects Versions: 3.1.1
> Reporter: Christopher G. Stach II
> Assignee: Diego Pires Plentz
> Priority: Minor
> Fix For: 3.3
>
>
> This may be an Annotations bug (3.1beta8), bug the exception happens in Core.
> This column used to pass when I used this:
> @Column(columnDefinition = "INT UNSIGNED NOT NULL DEFAULT 0", nullable = false)
> I have since changed it to
> @Column(columnDefinition = "INT UNSIGNED DEFAULT 0", nullable = false)
> because "nullable = false" adds the "not null".
> I am guessing that the nullable isn't being used in the validateColumns. I have not yet investigated, but the stack trace is below.
> org.hibernate.tool.hbm2ddl.TableMetadata.<init> table found: xxx.yyy
> org.hibernate.tool.hbm2ddl.TableMetadata.<init> columns: [foo_id, ipaddress, actiontype, timestamp, id]
> com.caucho.server.webapp.Application.start org.hibernate.HibernateException: Wrong column type: ipAddress, expected: INT UNSIGNED DEFAULT 0
> at org.hibernate.mapping.Table.validateColumns(Table.java:219)
> at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:964)
> at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1164)
> [...]
--
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
17 years, 5 months
[Hibernate-JIRA] Created: (HHH-2503) AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
by Dag Liodden (JIRA)
AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
-----------------------------------------------------------------------------
Key: HHH-2503
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2503
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.2, 3.2.3
Environment: 3.2.2GA and trunk
Reporter: Dag Liodden
Seems to be a small typo on line 3718 in AbstractEntityPersister (trunk and 3.2.2 GA) which makes exceptions during property generation being logged but not thrown:
catch( SQLException sqle ) {
JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
There should be a throw in there I guess. :)
catch( SQLException sqle ) {
throw JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
This bug will not be noticeable in most cases and is probably why it hasn't been detected / fixed so far. The method in question (processGeneratedProperties) is used for retrieving properties that are marked as "generated" in the mapping document / annotations - in other words any value that the database provides and is considered "read-only" from the Hibernate application's point of view.
The generated value is retrieved by an extra select statement executed by Hibernate after an entity has been inserterd and / or updated (according to how the generated property is flagged). In my particular case, a property (not a key) is marked as generated="insert", so after Hibernate inserts a new entity to the database, it will immediately do a select and set the generated property to the value the database returns.
Only in rare cases will this select fail in any way - in fact, I cannot think of any situations other than mapping errors (e.g getInt on a CHAR column) that can cause errors in this last select. That is in addition to my situation - a deadlock.
My entity class uses uuid.hex generator for the PK, but at one point, we introduced a second unique key due to purely aestethic reasons. This is a SQL Server identity column. Since we don't do any explicit table locking during the inserts, we end up with deadlocks every time the following happens:
T1: INSERT INTO TABLE (ID) values (?)
T2: INSERT INTO TABLE (ID) values (?)
T2: SELECT GENERATED_ID FROM TABLE WHERE ID = ? -- T1's insert hasn't been committed, so what should the the generated ID be? Deadlock!
T1: SELECT GENERATED_ID FROM TABLE WHERE ID = ?
...
SQL Server throws an error to indicate the deadlock, but due to the missing throw in the processGeneratedProperties-method, it is never shown to the process doing the insert. The generated property is not set and retains it's null (or 0 in case of a primitive) without the business logic ever knowing that the entity could not be saved.
--
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
17 years, 5 months
[Hibernate-JIRA] Created: (HHH-2320) Regression: optional properties under a <join> tag no longer update properly
by Chris Jones (JIRA)
Regression: optional properties under a <join> tag no longer update properly
----------------------------------------------------------------------------
Key: HHH-2320
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2320
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.0.cr4, 3.2.0.ga, 3.2.0.cr5
Environment: hibernate 3.2.0.cr4 through 3.2.1.ga
hsql 1.8.0.7 and Oracle 9i
Reporter: Chris Jones
This was specifically introduced with the revision 10217 changes on the 3.2 branch in src/org/hibernate/persister/entity/AbstractEntityPersister.java
Given the following setup:
<class name="Thing">
<id .../>
<join table="JOIN_TABLE" optional="true">
<key column="THING_ID" not-null="true"/>
<property name="joinedProperty" column="JOINED_PROPERTY"/>
</join>
</class>
scenario:
Thing thing1 = new Thing();
thing1.setJoinedProperty("thing1");
save(thing1);
// a record in the JOIN_TABLE is created properly and updates on the property can occur
Thing thing2 = new Thing();
thing2.setJoinedProperty(null);
save(thing2);
// no record in JOIN_TABLE is created
thing2.setJoinedProperty("thing2");
save(thing2);
// in revision 10216, hibernate correctly runs an INSERT to create a JOIN_TABLE record with the value "thing2"
// in revision 10217, hibernate incorrectly runs an UPDATE to try and update a non-existant record in the JOIN_TABLE with the thing2 id
It looks like the expectation.verifyOutcome() method should be throwing a StaleStateException if the attempted update effects 0 rows.
I will try and get an official hibernate testcase going and possibly a patch, but I wanted to enter this now in case there is something I'm missing that makes this change in functionality intentional.
--
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
17 years, 5 months