Databases Reference
In-Depth Information
fall into current assertion time. The mechanics of withdrawal
supports these different semantics correctly, just as it supported
the semantics of non-deferrals correctly.
Deferred update and delete transactions may also have
deferred assertions as their target. However, for any
oid
and
any effective-time clock tick, the target of a deferred update or
delete transaction must be the
latest
assertion of that effective-
time clock tick for that object because, if it were not, it would
violate the serialization property of deferred assertions (as
described earlier, in the section
A Deferred Update to a Current
Episode
). And the AVF guarantees that this will be so because
any but the latest assertion will be locked; it will be on a row
with a non-12/31/9999 assertion end date.
Themechanics of the AVFdoes its job, as in the first two cases, by
ending the withdrawn assertions on the same clock tick that their
replacement and/or superceding versions begin to be asserted.
For example, P861(r8) has an assertion begin date of January
2090. If a deferred update transaction targeting P861(r8) speci-
fied any assertion date later than that, then it would leave P861
(r8) to become currently asserted on January 2090, and to
remain currently asserted until whatever assertion end date the
transaction assigned to it. That's an ordinary enough case, and
perhaps we should not be surprised that the machinery of defer-
ral works correctly for it. But in fact, the deferred update we are
discussing here specifies an assertion date of January 2090, the
same date as the begin date on the target deferred assertion.
And this is not so ordinary a case.
But in this case, too, what the mechanics achieves is precisely
what the semantics demands. In this case, P861(r8)'s assertion
end date is set to January 2090, with the result that its assertion
time period is [Jan 2090 - Jan 2090]. With a closed-open conven-
tion for representing periods of time, this is an empty time
period, one including not a single clock tick. It makes it as
though P861(r8) had never been. It makes that row one which
never was asserted and never will be asserted. For such rows,
we will say, the transaction
overrides
them. So, to override a
row is to withdraw it into empty assertion time prior to its ever
being asserted in the first place.
What the semantics demands is a replacement row and a
superceding row to cover the months of May and June 2012 in
the life of P861, and for both those rows to begin to be asserted
on January 2090. With P861(r9 & r10), that's exactly what it gets.
There is now a target row which exactly matches the update
transaction, and the transaction can now proceed on to
completion.
