Applicable version: v2.5.0
Description
The Directory Search feature added in SSP v2.5.0 included a materialized view to operationalizeThe Caseload list and Student Search results are based on a materialized view created during the development of SSP 2.5.0.
Person Directory Processes
Refresh Process | Refresh Steps |
|---|---|
| The refresh process is the same regardless of the trigger to execute the refresh. Below are a list of the triggers that update the views/tables. |
|
| Refresh Triggers | Trigger Description |
| Application startup | When the application starts, the Primary and Secondary Person Directories are updated from all data sources per the following steps: |
| External person sync | Per the task_external_person_sync_trigger configuration, the external person sync process executes. As soon as it completes, the directory refresh steps execute per the following steps: |
| Directory person refresh trigger | Per the task_directory_person_refresh_trigger, the refresh process can be executed per a schedule. By default, the trigger is disabled |
| Operational triggers |
SQL Server Database Object Definitions
| Description | Type | Object |
|---|---|---|
| Directory Definition | View | v_directory_person |
| Primary Person Directory | Table (materialized view) | mv_directory_person |
| Secondary Person Directory | Table (materialized view) | mv_directory_person_blue |
| Procedure to refresh the Primary Person Directory | Stored Procedure | REFRESH_MV_DIRECTORY_PERSON |
| Procedure to refresh the Secondary Person Directory | Stored Procedure | REFRESH_MV_DIRECTORY_PERSON_BLUE |
| Procedure to update the Primary Person Directory per transaction | Stored Procedure | update_directory_person_from_view_where_person_id |
| Procedure to update the Primary Person Directory per transaction | Stored Procedure | update_directory_person_from_view_where_school_id |
PostgreSQL Database Object Definitions
| Description | Type | Object |
|---|---|---|
| Directory Definition | View | v_directory_person |
| Primary Person Directory | Table (materialized view) | mv_directory_person |
| Secondary Person Directory | Table (materialized view) | mv_directory_person_blue |
| Procedure to refresh the Primary Person Directory | Function | refresh_mv_directory_person |
| Procedure to refresh the Secondary Person Directory | Function | refresh_mv_directory_person_blue |
| Trigger to update the Primary Person Directory per transaction | Trigger Function | update_directory_person_from_view_where_person_id |
| Trigger to update the Primary Person Directory per transaction | Trigger Function | update_directory_person_from_view_where_school_id |
| Trigger to update the Primary Person Directory per transaction | Trigger Function | update_directory_person_from_view_early_alert_id |
Considerations
There are situations based on the timing of events whereby the Caseload list and Student Search may temporarily not be the most current. Based on the default task schedule configurations and known usage, the possibility of stale data is low and during low traffic periods. The following scenarios may result in stale data.
- The time between the load of the external data and the completion of the refresh triggered by the external person sync.
- The time during the use of the Secondary Person Directory that doesn't include the result of a triggered event (program status change, Early Alert submission and response)
Outside of the scenarios described above, the solution to updating stale data is to enable the task_directory_person_refresh_trigger and set for a time to execute the refresh process