Aperi Database R2 Extensibility

How do I coordinate a database schema change?

This section assumes that the person is familiar with the Database Component Design (MS Word).

When some database change is needed, the team member responsible for the work item (referred as the requester) will analyze the application requirements, draft the database changes on schema, helper, mapper, detectability with the help of the entire design team The requester should analyze the impact of the changes on the whole of Aperi.

The change request will be reviewed and approved by a deadline, by the design team (led by the database team lead). If needed, the committee may request consultation from special expertise area.

The requester will be responsible for the implementation of the change, and negotiate any resource issue if there is a need. The requester should test the new schema file(s) by using them to replace the corresponding files in a proper version of Aperi. The requester should make an overall build with all the changes to ensure nothing breaks. The requester will send out a note to the aperi-dev mailing list highlighting the change.

How do I analyze the impact of a database schema change?

The following changes usually have no impact on Aperi:

1. Add a table, view, column, index (including primary key). An important thing to note is that a new name might conflict with existing ones (See the Helper documentation in the Database Component Design (MS Word) for more details). For example, the table name T_TSM_SERVER conflicts with T_RES_SERVER.

The following changes might have an impact on Aperi:

1. Delete a table, view, column
2. Change the data type of a column
3. Change the encoding of data
4. Delete a primary key, index
5. Change table data population

Changes to the data type of a column are not recommended.

It may be necessary to regenerate a dependent view if a table definition is changed.