Databases Reference
In-Depth Information
Restricted and Unrestricted Temporal Transactions
The temporal update transactions discussed in this topic are
restricted temporal updates. By that we mean that these trans-
actions designate a specific object, a span of effective time, and
a value for one or more columns of business data, and then
change all representations of that object, in all clock ticks within
that timespan, to those new values. But limited to only restricted
update transactions, Asserted Versioning could not, for example,
change the copay amounts on all policies within a target
timespan provided that the original amounts are less than a cer-
tain value. Instead, the AVF could only change all copay amounts
within that timespan, for a single object, to that new value.
Obviously, a series of carefully designed restricted temporal
updates could produce any desired result, and do so across any
set of objects. But just as obviously, it would be a tedious process.
And because of the careful analysis required, it would also be an
error-prone process.
As we go to press, these limitations on temporal update trans-
actions have been removed. Release 1 of our Asserted Versioning
Framework now supports unrestricted temporal update trans-
actions, ones which will update multiple objects within a target
timespan, and will do so based on WHERE clause qualifying
criteria. The AVF also now supports unrestricted temporal
deletes as well.
In addition, instead of requiring the user to write trans-
actions in a proprietary format required by an Application
Programming Interface (API) we were developing, the AVF
now accepts temporal insert, update and delete transactions
written as native SQL. This is done by means of Instead of
Triggers, as described in the section Ongoing Research and
Development, in Chapter 16.
Our new support for unrestricted temporal transactions,
written as native SQL statements, can be found on our website
AssertedVersioning.com.
The Temporal Delete Transaction
A temporal delete transaction specifies an object and a target
range for the transaction (
Figure 10.13
). It includes the object
identifier, if it is known to the user. If an oid is not provided on
the transaction, the AVF attempts to find one according to the
rules described in the previous chapter. Finally, the transaction
either accepts the default values for its temporal parameters, or
overrides one or more of them with explicit values.
