Validation performance issues

There are three ways in which validation can cause performance problems:

  • The rules themselves are too performance intensive.
  • There are too many objects being validated.
  • The queries used to determine which objects to validate take too long.
The following items can all create performance issues.
Validating large amounts of administration objects
Guidewire recommends that you never mark foreign keys and arrays that point to administration objects—such as User or Group objects—as triggering validation. An administration object is any object that a large number of other policies can reference. For example, suppose that you set the Group field on Policy to trigger validation. Editing one policy can then bring the entire application to a crawl as PolicyCenter validated hundreds or even thousands of policies. Setting this particular validation trigger would make editing policy objects nearly impossible.
Length of query paths
In some cases, an entity can have a large number of foreign keys pointing at it. Triggering validation on the entity can cause performance problems, as PolicyCenter must follow each of those chains of relationships during validation. The longer the paths through the tables, the more expensive the queries that PolicyCenter executes any time that an object changes. Having a consistent direction for graph references helps to avoid this.
Triggering validation on parent-pointing foreign keys on entities that have many possible owners (like account contact) can result in much longer and unintended paths. For example, a number of entities point to AccountContact. Each of these entities then contains links to other entities. Validating the entire web of relationships can have a serious negative performance impact.
Guidewire designs the PolicyCenter default configuration to minimize this issue. However, heavy modification of the default configuration using validation trigger overrides can introduce unintended performance issues.
Links between top-level objects
It is legal to have top-level entities trigger validation on each other. This use of validation triggers, however, can unnecessarily increase the number of paths and the number of objects that PolicyCenter must validate on any particular commit.
Graph direction inconsistency
In general, Guidewire strongly recommends that you consistently order the validation graph to avoid problems:
  • PolicyCenter consider arrays and foreign keys that represent some sort of containment as candidates for triggering validation.
  • PolicyCenter does not consider foreign keys that you reference as arrays or that are merely there to indicate association as candidates for triggering validation.
Illegal links and arrays
Virtual foreign keys cannot trigger validation because PolicyCenter does not store them in the database. Attempting to use a virtual foreign key to trigger validation causes PolicyCenter to report an error at application startup. Similarly, it is not possible to set any array or link property defined at the application level (such as the Driver link on Policy) to trigger validation.
PolicyCenter considers an array to be in the database if the foreign key that forms the array is in the database.