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;
}