Update resource¶

Initial validation¶

Initial validation is performed at the very beginning of the resource update process. It checks:

• whether given input data represent a valid resource ingestion configuration object

• whether a resource with given id and resourceId exists

Custom validation¶

Custom validation is executed just after initial validation. It is a part of the process which is designed to be customized with the connector-specific logic.

By default, it invokes PUBLIC.UPDATE_RESOURCE_VALIDATE(resource_ingestion_definition_id VARCHAR, ingestion_configurations VARIANT), which returns 'response_code': 'OK'. It can be overwritten through the SQL script or by using a UpdateResourceHandlerBuilder to provide custom implementation of the UpdateResourceValidator interface.

If the custom validation returns error, the next steps will not be executed and given error response will be returned from UPDATE_RESOURCE procedure.

Custom logic before a resource is updated¶

Custom logic can be defined and executed before a resource is updated and rescheduled.

By default, it invokes PUBLIC.PRE_UPDATE_RESOURCE(resource_ingestion_definition_id VARCHAR, ingestion_configurations VARIANT), which returns 'response_code': 'OK'. It can be overwritten through the SQL script or by using a UpdateResourceHandlerBuilder to provide custom implementation of the PreUpdateResourceCallback interface.

If custom logic returns error, the next steps will not be executed and given error response will be returned from UPDATE_RESOURCE procedure.

Update of resource ingestion configurations¶

Within this step a new ingestion configurations are saved to STATE.RESOURCE_INGESTION_DEFINITION table for the resource with a given resource_ingestion_definition_id.

Finishing ingestion processes for removed ingestion configurations¶

In this step, when a resource is enabled (enabled parameter equals true) all active ingestion processes (with statuses SCHEDULED or IN_PROGRESS) with ingestion configurations that ids aren’t included in the set of updated ingestion configurations are finished, which means that their status is switched to FINISHED.

Scheduling ingestion processes for new ingestion configuration¶

In this step, when a resource is enabled (enabled parameter equals true) new ingestion processes are created for updated ingestion configurations that didn’t exist in a previous ingestion configurations state for a given resource.

Custom logic after a resource is updated¶

Custom logic can be implemented and executed after resource ingestion configurations are updated.

By default, it invokes PUBLIC.POST_UPDATE_RESOURCE(resource_ingestion_definition_id VARCHAR, ingestion_configurations VARIANT), which returns 'response_code': 'OK'. It can be overwritten through the SQL script or by using a UpdateResourceHandlerBuilder to provide custom implementation of the PostUpdateResourceCallback interface.

If custom logic returns an error, the given error response will be returned from UPDATE_RESOURCE procedure but the update of resource ingestion definition and ingestion processes will not be rolled back so if required, it should be handled by the custom implementation.

Response¶