Re: [hibernate-dev] mutable versus immutable natural keys
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;
}
?
On 12/07/2011 08:08 PM, Steve Ebersole wrote:
Part of the problem with saying that a natural key is immutable is
when
entities are reattached. We do not know whether the application is
attempting to update the value. The only solution there is again to read
the database snapshot and compare values. Unfortunately that wont tell
us whether this process is trying to change the value or whether the
value has changed in the database. But in either case we have a
violation of the immutability.
So I guess it will be more clear to say that immutable forces those checks.
On Wed 07 Dec 2011 09:47:22 AM CST, Steve Ebersole wrote:
> 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.
>
>
--
steve(a)hibernate.org
http://hibernate.org