On 28 févr. 2012, at 17:59, Steve Ebersole wrote: I agree with you.

John Verhaeg wrote: I probably don't understand the complexities with this, but wouldn't the ID values in AA have to be completely independent of the values in A? Yes, that's exactly what I'd expected originally and that's it what would be a nice to have ! In our model for example we have following entity classes: class Article { @Id Id generated key; @NaturalId String articlenumber; } class Carton extends Article { @NaturalId int cartonId; } so it would be nice to can lookup a Carton as well as through its articleNumber session.bySimpleNaturalId(Article.class).load("04712342"); as well as through it's carton number session.bySimpleNaturalId(Carton.class).load(10); As said, this would be a nice to have (maybe in a future release), but I can also live without. @Steve: As you rejected issue "HHH-7113 NaturalIdLoadAccess not properly working on mutable NaturalId's" you force me to re-open the issue again because HHH-7113 actually intended to address following 2 bugs: 1. After updating the value of a mutable NaturalId, the entity object can be retrieved with the new value, but also with the old value. On deletions the internal NaturalId cache is synchronized properly but not on modifications. 2. When inserting or deleting an entity object, the entity-persister of the object's concrete class is considered as cache-region. When loading an entity object by NaturalId , indeed the entity-persister of the declaring class is considered as cache-region ( Session.byNaturalId(declaringclass))). As declaringclass may be a superclass of the concrete class, the NaturalId-synchronisation may try to synchronize the wrong cache-region. THIS 2 BUGS ARE ALSO HAPPENING WITH NATURALID'S DECLARED EXCLUSIVELY IN ROOT CLASS! I will open regarding issue with testcase asap. best regards G.Demetz

(articlenumber) is already unique. So what is the point of (articlenumber,cartonId)? Your description and proposed fix of HHH-7113 all centered around choosing the "right persister" to use for cache keys, so I naturally assumed the problem was due to the unsupported way you were defining the natural ids. If the bug exists even with correctly defined natural ids then we will get it fixed. I don't understand what you are getting at with your (2). Caching should be using the root persister of the hierarchy for cache keys. But if you feel there is a bug, open a JIRA *with a test case*. Thanks On 03/01/2012 04:09 AM, Demetz, Guenther wrote:

Cool, I will look this afternoon. On Thu 01 Mar 2012 09:21:17 AM CST, Demetz, Guenther wrote: -- steve(a)hibernate.org http://hibernate.org

Hi Steve, Hm, it probably depends on how you fixed HHH-7129. Is following hierarchy allowed after HHH-7129 ? @Entity class A { @Id int id; } @Entity class Subclass1 extends A { @NaturalId String name; } @Entity class Subclass2 extends A { @NaturalId String card; } If it is still allowed, then caching session.bySimpleNaturalId(SubClass2.class).load("g"); should't use the root persisterA, it should use persisterSubclass2, otherwise session.bySimpleNaturalId(SubClass1.class).load("g"); would overwrite the previous cached entry, right?