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
