Custom Change Detection

There may be situations where automatic detection of changes is unsuitable, perhaps because changes need to be detected in a very indirect way. In order to handle this there is the option to use custom change detection, where the model itself determines what changes have occurred. To use custom change handling, simply use the key word 'customchangehandler' in the data fetch and specify the name of a function that will return the changes, e.g. 'customchangehandler = Get_Activity_Changes;'. The template model will then generate a stub method which should be overridden in the model plsql file.

It is worth noting that it is still possible to use triggers with custom change detection. Simply specify the triggers you wish to be added in the normal way, and changes will be logged in the Scheduling_Change_Log table, and consequently added to the Scheduling_Transfer_Log table when the update changes job is processing. The custom change handler function takes as input the unique transfer_id in the parameter 'context_.transfer_id' which can then be used to lookup the changes relevant for the particular update changes job from the Scheduling_Transfer_Log table *.

The custom change handler method should return a pipelined array of records of the same type as a the data fetch, e.g. a custom change handler for an Activity data fetch should return a pipelined array of Scheduling_SYS.Activity_Rec rows. This will be clear from the default function that is created by the template.

To specify that a row is a deletion, simply set the _is_deleted_ flag on the record to 1. It is only necessary to include the primary key attributes on such records.

* For backwards compatibility the custom change handler function also takes as input the last_change_log_id which can be used to lookup any changes that have occurred since this point for the specified triggers directly from the Scheduling_Change_Log table. However, the recommendation is to use the Scheduling_Transfer_Log table for the lookup of changes.