Re: [hibernate-dev] mutable versus immutable natural keys
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