NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.
Ok, but what if you have a trigger that updates this field in some cases and sometimes doesn’t? For example, you may have a document number that is generated for some types of documents, and set by the user for other types. You cannot do this with NHibernate in a regular way – but there is a workaround…
It is possible to map multiple properties to the same database column. So, if you make a non-generated property that is writable, and a generated read-only property, this works. You have to be careful, though, because the non-generated property’s value won’t be refreshed after database writes.
A more secure solution would be to make one of the properties non-public and implement the other one to support both functionalities. Like this:
//
// This field is used only to send a value to the database trigger:
// the value set here will be written to the database table and can be consumed by
// the trigger. But it will not be refreshed if the value was changed by the trigger.
//
private int? setDocumentNumber;
private int? _documentnumber;
//
// The public property that works as expected, generated but not read-only//
public int? DocumentNumber
{
get { return _documentnumber; }
set
{
// NHibernate is indifferent to this property's value (it will not
// be written to the database), so we have to update the setDocumentNumber
// field which is regularly mapped
_documentnumber = value;
setDocumentNumber = value;
}
}
Here’s the NHibernate mapping for these two:
<property name="DocumentNumber" generated="always" insert="false" update="false"/> <property name="setDocumentNumber" column="DocumentNumber" access="field"/>