Hibernate version: NHibernate 1.2.0.GA

I am trying to figure out how to get NHibernate working with our valid time temporal database. The database is an Oracle database and every table has a valid time table, therefore every table needs a VALID_FROM and VALID_TO column in it. There is no data, other than the surrogate key, that doesn't need to be versioned. By that I mean that the business value of this versioning is for reporting purposes between periods and being able to look at a previous state of the data. Even the name of an entity can change completely between versions, we only need to keep track of which name it used to possess.

I can see three solutions:

1) Applying the filter available in NHibernate. This is specifically enabled for temporal data, and works wonderfully for classes and one-to-many collections. It doesn't work for many-to-one relationships though, as described at http://forum.hibernate.org/viewtopic.ph ... poral+data. I completely agree with mgl, without this feature there is no way temporal data can be supported as part of Hibernate. (Or if it can, I'd like to know how this is done.)

2) Use the Workspace Manager Valid Time Support that is part of Oracle, described at http://download-west.oracle.com/docs/cd ... ong_vt.htm. This is a possible solution but I do not know how well it will work with Hibernate. From the issues that user530397 has at http://forums.oracle.com/forums/thread. ... ID=1551355 I suspect this would be a non-trivial implementation.

3) Create a table and table_version for each table in the database, as VampBoy discusses at http://forum.hibernate.org/viewtopic.ph ... poral+data. Since every table in our system would need this and has no other data that will not be versioned, this is a poor solution for us. We'd have a table with nothing but unique surrogate keys and all the other data (including duplicates of the surrogate key) in the table_version table.

The best solution I can see is the implementation of many-to-one filters in Hibernate. Option two, I believe, will be fraught with issues. Option three almost isn't really an option at all, we'd be changing our data model solely for the purpose of making it work correctly with Hibernate. I'd rather drop Hibernate than double the number of tables in our database.

I would be very appreciative of any suggestions people have. I've been working on this issue for some time now and can't find a way to do this that wouldn't cause many potential issues.