We do the following:
We have a class VAT mapped with <cache usage="read-only"/>.
In a setup program using NHibernate, we do (about) the following:
VAT v = new VAT();
v.Percentage = 19.0;
v.Name = "Full VAT";
session.Save(v);
This works.
In a test case, someone wrote:
VAT v = new VAT();
session.Save(v);
v.Percentage = 19.0;
v.Name = "Full VAT";
...flush+commit follows much later...
This leads to an InvalidOperationException "Can't write to a readonly object" from the class ReadonlyCache's Lock method.
The behavior stems from the fact that NHibernate (and, AFAIK, Hibernate) creates a new object in a somewhat roundabout way: It remembers the object exactly at the point of the Save(); and then does a compare when it flushes the new object. From these, it emits an INSERT and an UPDATE.
---> If this behavior is stable (you *can* create a new object with a *readonly-cache* if you take care that no changes are done after Save()) and will be supported for all future, we are happy and will use this idiom.
---> If not, how should a program work that wants to insert objects for a class marked with <cache usage="read-only"/>?
Regards
Harald M.
|