After our conversion in IRC I think the latest iteration of the idea having the following would suffice: public @interface NaturalId { /** * If the NaturalId can change, either via the application or direct database manipulation */ boolean mutable() default false; /** * If the NaturalId->PrimaryKey resolution should be stored in the L2 cache */ boolean cache() default true; } I think we can do away with IMMUTABLE vs IMMUTABLE_CHECKED and simply always do the consistency check when detached entities with natural ids are attached. As for the conflict of doing something like: @NaturalId @Column(updatable=true) private String userName; I think the solution is to log a warning along the lines of "com.example.User.userName is marked as an immutable NaturalId and always marked as updatable, the updatable flag will be ignored" -Eric On 01/17/2012 02:18 PM, steve(a)hibernate.org wrote: In talking with few people that use this feature, there is def a desire to account for both immutable-with-checking and immutable-without-checking. Initially I started down the path of an enum to model this: public enum NaturalIdMutability { MUTABLE, IMMUTABLE, IMMUTABLE_CHECKED, @Deprecated UNSPECIFIED } and: public @interface NaturalId { @Deprecated boolean mutable() default false; NaturalIdMutability mutability() default NaturalIdMutability.UNSPECIFIED; } But I started to think it might be better to instead separate the definition of mutable/immutable and whether or not to do checking on immutable. What is the difference in folks minds between: public class User { ... @NaturalId(mutable=false) private String userName; } and public class User { ... @NaturalId @Column(updatable=false) private String userName; } ? Or is everyone ok with this form: public class User { ... @NaturalId(mutability=NaturalIdMutability.MUTABLE) private String userName; } and if so, how should this be interpreted: public class User { ... @NaturalId(mutability=NaturalIdMutability.IMMMUTABLE) @Column(updatable=true) private String userName; }