NaturalIdCacheKey equals method doesn't work for primitive array types ---------------------------------------------------------------------- Key: HHH-7258 URL: https://hibernate.onjira.com/browse/HHH-7258 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Environment: Hibernate 4.1.2 SQL 2008 Reporter: Steve Ash I have entities like (shorthand): {code} @Entity @Cache public class Parent { @Id private byte[] id; } @Entity @Cache @NaturalIdCache public class Child { @Id private byte[] id; @ManyToOne @NaturalId private Parent parent; @NaturalId private String name; } {code} So the naturalId is a compound key made up of a FK reference to the parent + the name of the child (i.e. for a single parent, all of the childrens names are unique). I always get a cache miss in the 2nd level cache when I try to load this by natural key using something like: {code} Parent p = ... // attached parent instance return sf.getCurrentSession() .byNaturalId(Child.class) .using("parent", p) .using("name", childName) .load(); {code} I stepped through the code and found that eventually an instance of {{NaturalIdCacheKey}} is built with a field {{naturalIdValues}}. In the Child instance above this naturalIdValues would be an array of size 2. The [0] element is a byte[] reference, and the [1] element is the child name string. While I can see in the debugger that my Child instance is present in the natural Id cache, the equals method on NaturalIdCacheKey just uses Array.equals on naturalIdValues. Thus, it does a reference equals on my primitive byte[] for the parent's PK value. While the values in the byte array are the same, they are different instances of course, and thus the reference equals returns false, and I never retrieve this from the natural id cache. Thinking I would be clever, I replaced this with an @Embeddable component that wrapped the byte[] and implemented my own equals, but Hibernate core _disassembles_ the component to build the naturalIdCacheKey which defeats my component and so we end up with the same problem. I have run in to a similar problem in HHH-7180 so clearly theres not too many of us that are using binary storage for GUIDs. Is everyone else just storing as 32byte strings? Or 22 byte case-sensitive coalation strings? Or an @embedded with two longs? I'll build a test case that replicates this at some point soon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira