Validation graph in ContactManager

During database commit, ContactManager performs validation on the following entities:

• Any validatable entity that is itself either updated or inserted.
• Any validatable entity that refers to an entity that has been updated, inserted, or removed.

ContactManager gathers all the entities that reference a changed entity into a virtual graph. This graph maps all paths from each type of entity to the top-level validatable entity, such as ABContact. These paths are queried in the database or in memory to determine which validatable entities, if any, refer to the entity that was inserted, updated, or removed.

ContactManager determines the validation graph by traversing the set of foreign keys and arrays that trigger validation. For example, suppose that the data model marks the Address array on ABContact as triggering validation. Therefore, any changes made to an address causes the Rules engine to validate the contact as well.

ContactManager follows foreign keys and arrays that trigger validation through any links and arrays on the referenced entities down the object tree. For example, you might end up with a path like ABContact → ABContactAddress → Address. To actually trigger validation, each link in the chain—Address and ABContactAddress—must be marked as triggering validation, and ABContact must implement the Validatable delegate.

ContactManager stores this path in reverse order in the validation graph. Thus, if an address changes, ContactManager follows the path to find the contact that references a changed address. ContactManager transverses the tree from address to contact address, and finally to the contact—Address → ABContactAddress → ABContact.