Implications of modifying the data model

Removing a data model extension or a column in an extension retains the data for the table or column in the database. You can create an upgrade trigger to remove the data if you are certain that it has no value. Removing a data object is typically valid only in your development environment. If you build a new configuration, it can sometimes be necessary to remove an extension rather than to drop and recreate the database. Dropping the database destroys any data that currently exists. If you share a database instance with multiple developers, removing the extension is less disruptive for the development team.

During server start up, PolicyCenter checks for configuration changes, such as modified extensions, that require a database upgrade. If the database structure does not match the data model configuration, PolicyCenter writes a warning message to the log file.

For some modifications to a data object, the application upgrade process cannot make the corresponding database modification for you. The database upgrade tool is unable to implement extension modifications that require it to do any of the following:

• Delete a column.
• Add a non-nullable column.
• Change a column from nullable to non-nullable if null values exist in the database column or if there is not a default value.
• Change the underlying data type of a column, such as changing a varchar column to clob or varchar column to int.
• Shorten the length or type of a varchar or other text-based column, if this change truncates data in the column, such as changing a mediumtext column to shorttext. If shortening the length does not require truncating existing data, the upgrader can handle both shortening the length of a varchar column and increasing the length of a varchar column. The upgrader can increase the length of a varchar column up to 8000 characters for SQL Server.

For many of the changes that you make to the data model, Guidewire provides version triggers that the database upgrader uses to make the applicable changes to the database. These changes are made on server start up if the application detects data model changes. The database upgrader cannot make some changes because there is no straightforward way to revise the data in affected columns. For example, if your change reduces the size of a varchar column, you might need to reduce the length of over-sized content by abbreviating standard phrases rather than by a simple truncation.

You can implement the IDatamodelUpgrade plugin and write IDatamodelChange upgrade triggers to synchronize the database with the data model. Guidewire supports the functions dropTable and dropColumn to assist in this process. Guidewire recommends using this approach to making changes to the database.

In many development environments, multiple developers all use the same database instance. Before modifying the data model, first you need to communicate with your team to make them aware of your planned changes. A good way to communicate your intentions is to provide the team with a list of files that refer to the affected data model extensions. After communicating with your team, follow a process similar to the following to remove a data model extension:

1. Remove the extension entity or entity extension using the methods outlined in the following sections:
   • Remove an extension entity type
   • Remove an extension to an entity type
2. Remove any references to the object in other parts of your configuration. If you do not remove these references, PolicyCenter displays error messages when attempting server start up and the server does not start.
3. Check in your changes.
4. Write code that supports the changes to the database. Implement the IDatamodelUpgrade plugin and write IDatamodelChange upgrade triggers.

   The code in the upgrade trigger runs when you start the PolicyCenter server.

5. Run the gwb compile command to update the resources that the PolicyCenter server uses.
6. Start the PolicyCenter server.

In a production environment, Guidewire recommends that you include formal testing and quality assurance before removing or modifying an extension. Also, involve your company database administrator (DBA) and any impacted departments. Guidewire recommends also that you document your change and the reasons for it.

It is possible to make changes to the data model that cause the data values in the database to become invalid. For example, you can change an integer column to a typekey column or the reverse, but integer values in the database might not map to a valid ID in the referenced typelist table. Similarly, removing typecodes from a typelist, instead of retiring them, might also cause data inconsistencies. If you have data that references a non-existent typecode, the database upgrade does not complete and the server refuses to start. Instead of removing typecodes, retire them instead.

You can remove an extension field or the entire entity from the data model. If you do this, the server logs an informational message to the console such as:

pcx_ex_ProviderServicedStates: mismatch in number of columns - 5 in data model, 6 in physical database