[hibernate-dev] mutable versus immutable natural keys

[Steve Ebersole]

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 at hibernate.org
http://hibernate.org