I am evaluating whether or not to use Hibernate for a new app that will re-use an existing Oracle DB schema that is used by many other applications. In this schema, nearly all of the tables have more than one column where default values are provided by triggers in situations where no value has been provided for that column (e.g. a logical deleted column (flag)). The symptom I am seeing in using Hibernate is that it will not allow the persistence of an object where a value has not been provided for one of these prior mentioned fields (columns they are not-null and a trigger provides a default value). So far I am not seeing an elegant solution to this. Below are things I have considered but ruled out
1) Having the hibernate data object provided a default value for the field
---- This is bad solution because you are duplicating what you think the trigger is going to do
2) Having the hibernate .hbm file define a default value for that object it supports (defines).
---- This is bad solution for same reason as 1
3) Change the table to allow nulls
---- This is a bad solution because other existing applications are relying on the functionality that have been getting out of the trigger. And secondly, because a middle tier layer should not be DB invasive.

What is the hibernate solution to this case?
The solution cannot be DB schema invasive in any way because of existing apps, and the solution cannot be a 're implementation' of what the triggers provide.
Thoughts?
Thanks!
Cheers,
Will-

I believe I have found an answer, and it involves using the attribute 'generated' with a value of 'insert'.
The entry looks like:
.........
<property name="lastModifiedDate" type="date" generated="insert">
<column name="LAST_MODIFIED_DATE" length="7" not-null="true">
<comment>Date the record was last modified.</comment>
</column>
</property>
.........