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.
>>
>>
>
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
