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

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