Changing the database schema to expose additional properties as columns requires planning. You should be a database administrator familiar with SQL, DDL, and database schemas with access to a database account and password that allows database restructuring (SQL ALTER TABLE grant).
Before modifying the schema, consider the following:
- In most cases, changes made to a table structure in a development or test system must also be made to the corresponding table in a production system.
- Exposing additional columns can affect the performance and tablespace requirements of the database, but has no functional effect on activities, the property, or other rules referencing the property. Column populator operations might require minutes or hours to complete. Perform column populator processing when rows of the affected table are not locked by other Pega Platform users (so no add, delete, or update operations occur during this process).
- If, in the Storage Stream (BLOB) column, the selected property or properties have non-blank values for at least some rows, you must extract (copy) the existing values into the new column by using the Column Populator utility.
- In a multinode cluster, new database columns are not visible on nodes other than the node that was used to expose the column, until the node is stopped and restarted. To simultaneously make the new column visible on all nodes, stop and restart the entire system.
- If the Pega Platform server connects to the selected database using a JDBC URL, the URL can include < and > characters. Some authentication and security software can be configured to reject URLs containing these characters. As a workaround, change the software settings to allow these characters.
Caution: The Storage Stream column ( pzPVStream ) of the
pr_operatorstable contains Operator ID passwords in an encrypted form. For maximum security of your Pega Platform system, do not alter the schema for this table to expose the password property as a column.