[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases

[Hontvári József (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=all ]

Hontvári József updated HHH-1569:
---------------------------------

    Attachment: ImmutableNaturalId-hibernate3.2.2.patch

The problem is still present in 3.2.2. I attached Tom Dunstan's patch but in the unified diff format and added the missing comment which caused the whole problem (that was the only undocumented function in that class...). 
I cannot follow the code, but it seems to me that quite a few lines deal with the problem that the usual loading functions don't load unmutable properties from the database. The same amount of code could be used instead to force loading of natural key values even if some of them are unmutable - they will be needed later when hibernate verifies that they were not changed accidentally.

> Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
> -------------------------------------------------------------------------
>
>          Key: HHH-1569
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>  Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases
>     Reporter: Tom Dunstan
>     Priority: Minor
>  Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip, ImmutableNaturalId-hibernate3.2.2.patch
>
>
> It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug.  It added the following lines:
> 	                         if ( loaded == null ) {
>   	                                 loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister );
>   	                         }
> Further down, loaded is used thusly:
> 				int prop = props[i];
> 				if ( !updateable[prop] ) {
> 					if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) {
> 						throw new HibernateException(
> Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays.
> I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable.
> Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used.
> (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2).

-- 
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