[hibernate-issues] [Hibernate-JIRA] Closed: (HHH-897) Cascades with assigned identifier in children not saving in 3.0.5

[Steve Ebersole (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Ebersole closed HHH-897.
------------------------------


Closing stale resolved issues

> Cascades with assigned identifier in children not saving in 3.0.5
> -----------------------------------------------------------------
>
>                 Key: HHH-897
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-897
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.0.5
>         Environment: Hibernate 3.0.5, Oracle 9i, Spring 1.2.2
>            Reporter: Rick Birch
>
> In section 22.4 of the Hibernate manual, the manual describes the correct action that should be taken when a cascaded subclass is being saved/updated:
> Well, that's all very well for the case of a generated identifier, but what about assigned identifiers and composite
> identifiers? This is more difficult, since Hibernate can't use the identifier property to distinguish between a
> newly instantiated object (with an identifier assigned by the user) and an object loaded in a previous session. In
> this case, Hibernate will either use the timestamp or version property, or will actually query the second-level
> cache or, worst case, the database, to see if the row exists.
> However, the code that does that in the BasicEntityPersister class public Boolean isTransient(Object entity, SessionImplementor session) method can never get to the second-level cache check.
> ....
> 		// check the id unsaved-value
> 		Boolean result = entityMetamodel.getIdentifierProperty()
> 				.getUnsavedValue().isUnsaved( id );
> 		if ( result != null ) return result;
> 		// check to see if it is in the second-level cache
> 		if ( hasCache() ) {
> 			CacheKey ck = new CacheKey( id, getIdentifierType(), getRootEntityName(), session.getEntityMode(), session.getFactory() );
> 			if ( getCache().get( ck, session.getTimestamp() ) != null ) return Boolean.FALSE;
> 		}
> If result from the entityMetamodel.getIdentifierProperty() .getUnsavedValue().isUnsaved( id ); is not null, then this if statement will return a result.  The Cascades.isUnsaved(id) method always returns a Boolean value, so the if (hasCache()) check can never be reached.
> 		public Boolean isUnsaved(Serializable id) {
> 			return id==null || id.equals(value) ? Boolean.TRUE : Boolean.FALSE;
> 		}
> For us, we'll be changing to generated keys.  But the assigned strategy works better with Unit Test code, allows for more predictable results.  Apologies in advanced if this is already fix in 3.1, but I didn't see any reference that I could interpret in the release notes for 3.1 beta.

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira