Overview of ContactManager preupdate and validation

ContactManager runs preupdate and validation rules every time it does a database bundle commit—commits data to the database. The validation rules execute after ContactManager runs all preupdate callbacks and preupdate rules. ContactManager runs the validation rules as the last step before writing data to the database.

Before applying rules during the bundle commit operation, ContactManager builds a validation object graph according to configuration settings. The graph contains possible targets for rule execution and is used by both the preupdate and the validation rules.

Preupdate rules, unlike validation rules, can modify additional objects during execution. Therefore, there can be additional objects that need to be constructed after the preupdate rules run and before the validation rules run.

Following are some examples indicating that the set of entities to be validated can be a super set of the entities for which preupdate rules are run:

Preupdate rules modify an entity that is not in the commit bundle

ContactManager can run additional validation rules if the entity being modified also triggers validation.

Preupdate rules modify only entities that are in the commit bundle

ContactManager runs the validation rules for the same set of entities on which the preupdate rules ran.

Preupdate rules modify an entity that triggers validation for one of the top-level entities

There is no difference from the top-level entity validation rules because they were already going to run.