One of the enhancements I want to get into 4.1 is HHH-2879 / HHH-2896 regarding adding an actual API for entity loading by natural key.

However, I think at the same time we should be more explicit and consistent about what it means when we say that a mapped natural key is mutable or immutable. Basically, is "immutable" a hint from the user that the values cannot change (so that we can perform certain optimizations)? Or is "immutable" a mandate that we have to verify the natural key has not changed, either through Hibernate or "behind" us? Today we kind of have a blend of those two. Personally I think we should take it as a hint from the user that the values will not change. WDYT?

There is a 3rd option in regards to immutable... to say that it is immutable, requiring a check. So: 1) mutable 2) immutable (no enforcement) 3) immutable (enforced) > Would the hint mechanism involve any detection of changed values at all? > What would the user see if a natural key were changed? The other thing that I did not draw out as well as I could, is where the value changed. Did it change as part of the Hibernate Session? Or did the value change in the database. It is this last bit that we do today when the user says immutable, that I dont think should always be getting done. Essentially, we are always checking the database snapshot for these entities to make sure this immutable natural key value did not change. I think that specifically should be an additional "opt in" behavior.

On Wed, Dec 7, 2011 at 6:08 PM, Steve Ebersole<steve(a)hibernate.org> wrote: > But in either case we have a > violation of the immutability. One of the use cases way back when I tried using Natural Keys was for accessing user accounts indexed by phone number. So 90% of our data access pattern was just mapping a phone number to a primary key, loading that entity, and the rest of the data would be cached... Phone numbers are interesting as they are considered immutable, but in the U.S. we infrequently have area code splits. There's also (fairly rare) cases where people update their phone number, say, if they move cities. Or, a phone number may be dropped and then later reused by an entirely different user. Maybe the user can expect some disruption in service but the expectation is service is available minutes after porting is done. There's also many issues dealing with various identities such as device ID or subscriber IDs. For example MIN versus MSISDN versus MDN. In all cases for a carrier we would store one of these values and then build an index with the others. The index is basically a table as such: class NumberMapping { @Id long id; String number; int type; // usually an enum Subscriber sub; } So you would select data using two columns "String, int" (not one). It would be nice to have NaturalKey be composite, if possible...Maybe declared as above? Or it might make sense to simply do like you do for composite @Id. @NaturalId class PhoneNumber { @Column String number; @Column int type; } @Immutable class NumberMapping { @Id long id; @NaturalId PhoneNumber number; @ManyToOne Subscriber sub; } The above is sort of venturing off-topic but maybe compound keys need to be discussed as well.