PolicyCenter database tables

For every entity type in the data model, PolicyCenter creates a table in the application database. For example, PolicyCenter creates a Policy table to store information about the Policy object.

In the application database, you can you identify an entity or extension table by the following prefix:

pc_

Entity table – one for each entity in the base configuration

pcx_

Extension table – one for each custom extension added to the extensions folder in Studio

Note: It is possible to create non-persistent entities. These are entities or objects that you cannot save to the database. Guidewire discourages the use of non-persistent entities in favor of Plain Old Gosu Objects (POGOs), instead. See <nonPersistentEntity> elements and related data object types for more information.

Besides entity tables, PolicyCenter creates the following types of tables in the database:

Table type

More information

shadow tables

Shadow tables

staging tables

Staging tables

temporary tables

Temporary (temp) tables

Shadow tables

A shadow table stores a copy of data from a main table for testing purposes. Every entity table potentially has a corresponding shadow table. Shadow tables in the database have one of the following prefixes:

pct_

Entity shadow table

pctt_

Typelist shadow table

Shadow tables provide a way to quickly save and restore test data. All GUnit tests, including those that you write yourself, use shadow tables automatically. You cannot prevent GUnit tests from using shadow tables. GUnit tests use shadow tables according to the following process:

  1. GUnit copies data from the main application tables to the shadow tables to create a backup of your test data.
  2. GUnit runs your tests.
  3. GUnit copies data backed up data in shadow tables to the main tables to restore a fresh copy of your test data for subsequent tests.

To start a test server, set its server.running.tests system property to true either explicitly or programmatically. In addition, set the server environment to one that uses your test database. Upon server startup, if shadow tables do not already exist, PolicyCenter drops the database, recreates it, and then creates the shadow tables. PolicyCenter creates shadow tables only in an empty database.

Staging tables

PolicyCenter generates a staging table for any entity that is marked with an attribute of loadable="true". The loadable attribute is true by default in the base configuration. A staging table largely parallels the main entity table except that:

  • PolicyCenter replaces foreign keys by PublicID objects of type String.
  • PolicyCenter replaces typecode fields by typekey objects of type String.

After you load data into these staging tables, you run the command line tool table_import to bulk load the staging table data into the main application database tables. See table_import command for information on how to use this command.

Important: Some data types, for example, Entity, contain an overwrittenInStagingTable attribute. If this attribute is set to true, then do not attempt to populate the associated staging table yourself because the loader import process overwrites this table.

In the application database, you can you identify a staging table by the following prefix pcst_.

Temporary (temp) tables

PolicyCenter generates a temporary table for any entity that is marked with an attribute of temporary="true". Do not confuse a temporary table with a shadow table, they are not synonymous. PolicyCenter uses temporary tables as work tables during installation or upgrade only. PolicyCenter does not use them if the server is running in standard operation.

Unfortunately, it is easy to forget to clear up these tables if they are no longer needed. Therefore, it is quite possible for an application to have several of these temporary tables remaining even though the upgrade triggers that used them are long gone.

In the application database, temporary tables look like any other entity table except that temporary tables are almost always empty.