Historical Client Sessions

By default, a session represents a view of the most current version of objects, and when you execute a query in that session, it returns the most current version of selected objects.

If your data source maintains past versions of objects, you can configure TopLink to access this historical data so that you can express read queries conditional on how your objects are changing over time. You can also so the following:

Make series of queries relative to any point in time–not just the time of the first query.
Provide read consistency so that a series of read operations or report queries all execute as if at the same time.
Use the deepMergeClone method to provide deep recovery of an object by passing in a past version of it.

In addition, you can express query selection criteria as either of the following:

A condition at a past time: for example, "employees who used to...".
A change over time: for example, "employees who recently...".

For more information, see the following:

Historical Client Session Limitations

The HistoryPolicy provides a very flexible means of accommodating a wide variety of historical schemas. However, be aware of the following restrictions:

You cannot use the HistoryPolicy, if your design combines both current and historical data in a single schema.
You cannot use historical sessions, nor historical queries, with EJB entity beans.
TopLink assumes that the current version of an object corresponds to the row in the historical table whose row end field is NULL.
You cannot directly map the start and end fields of a history table because they do not exist in the regular schema.
You cannot query on ranges of historical objects, only as of a specific point in time.