For version 0.6 and 0.8.4, I've noticed that if I map a class as immutable (<class ... mutable="false">), Session.Update() (followed by Session.Flush()) does not throw an exception. It updates the cached object but does not persist it to the database.

Is there a reason for this behavior? I imagine that this could cause problems for algorithms that operate on the cached instance.

The only way I can force nHibernate to throw is to utilize a read-only cache for the class type (by adding <jcs-cache usage="read-only"/> to the mapping file).

Can you just make the properties read-only rather than relying on NHibernate for this?

Yes I could, however, for a class with many properties, it seems infeasible to have to place the attribute on all of the properties. It is a good short-term fix, but it would be nice if the mutable class attribute took care of this for you.

If that were the case your API would allow something (a property change) that wouldn't be persisted. I think your DomainModel should not rely on NHibernate to work properly. In addition by not making read-only properites in your logical object model read only in your real object model, even if NHibernate did enforce it on a Save() then you are moving a simple compile time error to a runtime error. Yuck.

BOb

Both of you have valid points.

NHibernate should handle an immutable class as expected, or very clearly explain what immutable means in NHibernate.

And as a best practice, if a class isn't meant to be changed all properties should have getters only.

I've found it very important to remember that the classes have a very strong relationship with the mappings. If you are trying to use the clases for 2 different uses it may not work and you wil have to have seperate classes.