Constraint Evaluation Order at Record Validation Time

This figure illustrates the constraint evaluation order at record validation time:

The essence of record validation is that a record is being stored. All constraint evaluations taking place BEFORE the record is stored, are pre-store operations. Everything that occurs AFTER record storage, as a direct result of it, is a post-store operation.

The boxes in the illustration show that Update On Self constraints are handled pre-store. Typically, these constraints add further values to the record to be stored, or update some of the field values. At the end of pre-store handling, row checks occur. Post-store operations include reparations and the shortlisting of multi-record restrictive constraints on the violation list, to be evaluated at commit time.

The left part of the illustration shows that pre-store operations occur in a linear sequence, and all apply to the current row event only. This means they can be clearly ordered in time and their logic can be predicted and controlled. The Rules Engine takes advantage of this by putting these constraints in a certain order so that, if a pre-store constraint succeeds, a minimum of later pre-store constraints need to be evaluated. See also "Update On Self Sorting".

The actual store-record operation is the last atomic operation at record validation time. Post-store operations are characterized by low predictability. This is because they may give rise to other row events in other tables, which in turn may cause the evaluation of even more remote corrective constraints. This makes it very difficult to optimize post-store operations in a standardized manner.