Applying changes details
This section describes the rules PolicyCenter uses when applying changes for preemption (and
future renewals). In this topic, the phrase
the same object means objects with
the same fixed ID (matching
FixedID property values). The
fixed ID is discussed further in Policy revisioning.
To continue a preempted job PolicyCenter needs to:
- Create a new branch based on the most recently bound branch. PolicyCenter does this to ensure that no legally-binding changes are lost.
- Next, PolicyCenter calculates changes between the preempted branch (the one that did not yet bind) and the one it was based on.
- Finally, PolicyCenter applies those changes to the new branch.
To calculate branch differences, PolicyCenter generates
a set of difference item objects (DiffItem
objects) at a low-level database level. Each difference item represents
a change, such as a new object, a deleted object, or a change in a property.
PolicyCenter represents these different types of differences with subclasses
of DiffItem:
- New entities generate a DiffAdd object.
- Removed entities generate a DiffRemove object.
- Changed properties generate a DiffProperty object.
- Window changes (effective/expiration window) changes generate a DiffWindow object.
PolicyCenter uses different rules for applying changes for preemption based on each difference item subclass. The rules are similar but slightly different between preemption and applying changes to a future renewal.
The rules cover two aspects of applying the difference item in different cases:
- Can
this difference item subclass apply to the new branch? Whether the
DiffItemcan apply to the target branch. This essentially attempts to detect whether there is a potential conflict. This corresponds to eachDiffItemsubclass’s method canApplyDiffToBranch. - How to apply this difference to the branch?
If a difference item can apply to the target branch, how to perform it?
This corresponds to each
DiffItemsubclass’s method applyDiffToBranch.
The rules for applying changes to a renewal period are similar to the rules that govern handling a preemption. The major difference is that for applying changes to a renewal period, PolicyCenter only cares about applying changes effective at the end of the prior period. Only changes at the end of the period would naturally extend into the future renewal period. If a change in the prior period does not extend to the end of the period, PolicyCenter ignores it and does not consider it a conflict. PolicyCenter handles future renewals based on whether the future renewal is already bound. For information on how PolicyCenter handles the timing of applying changes, see Applying changes to future renewals.
The following table lists the rules for each difference subclass for both preemption and also for applying changes to future renewals:
Type |
For preemption, can apply change? |
For preemption, how to apply change? |
For future renewal, can apply change? |
For future renewal, how to apply change? |
|---|---|---|---|---|
|
Yes. |
Add entity instance to the new branch. In very rare cases where the period ranges of the preemption branch is different than the preempted branch, the entire entity instance does not fit into the new range. In this case, it shrinks or expands as necessary. |
Yes. |
Add entity instance to the new period as it looked at the end of the prior period. In the renewal branch it adds for the entire period range. Scalable properties adjust accordingly. If the entity instance terminates in the prior period before the period end, it does not add to the renewal period. |
|
Only if the removed entity instance exists in the new branch at the date when it was removed in the preempted branch. |
Remove the entity instance on the new branch at the expiration date. |
Only if the removed entity instance exists at the start of the renewal period. |
Remove the entity instance at the start of the renewal period. This effectively removes it entirely from the new branch. |
|
For a slice mode edit:
For a non-slice edit:
|
Get the entity instance on the preemption branch at the effective date of the change and set the property. |
If the changed entity instance exists at the start of the renewal period. |
Apply the property change only if the change in the prior period is effective through the end of the prior period’s range. If it is, then set the property at the start of the renewal period. Otherwise, the change is ignored. |
|
No. It is always a conflict. |
Not applicable. |
No. It is always a conflict. |
Not applicable. |
