[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-7206) Manage natural-id synchronization without flushing

[ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-7206: ------------------------------------- I have this working, for the most part. But here is a "rub" condition. I went at it a slightly different way, but your code suffers the same "rub". Take the test case {{org.hibernate.test.naturalid.mutable.MutableNaturalIdTest#testCacheSynchronizationOnMutation}} which is what i used to test this change out in terms of actually working. You have to remove the manual intermediate flush to get it to represent a more natural flow (and certainly the "in-line" natural-id updating flow you are advocating). So you have: {code:borderStyle=solid} Session s = openSession(); Transaction t = s.beginTransaction(); User u = new User( "gavin", "hb", "secret" ); s.persist( u ); t.commit(); s.close(); s = openSession(); s.beginTransaction(); u = (User) s.byId( User.class ).getReference( u.getId() ); u.setOrg( "ceylon" ); User oldNaturalId = (User) s.byNaturalId( User.class ).using( "name", "gavin" ).using( "org", "hb" ).load(); assertNull( oldNaturalId ); assertNotSame( u, oldNaturalId ); s.getTransaction().commit(); s.close(); {code} Basically we create an entity with natural id of ["gavin", "hb"]. We then change "hb" to "celyon" on the object and attempt to perform a lookup by the old natural id. This *should* result in a null result because that no longer exists. However, what really ends up happening is that the "dirty" detection finds the change and (correctly) removes the old cache entry and adds the new. But now when the lookup on the old natural id fails it reverts to the database and the old value is still there, so that is returned. Aside from writing the changes to the database at the same time, the only other option I can think of is to keep track of "no longer valid" natural id resolutions (i.e., keep around the fact that ["gavin", "hb"] is no longer valid and should return null) until the next flush cycle. Which I am not a huge fan of. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira