Job reset options

Reset options control how DataHub will re-evaluate tracking state or permission propagation on the next job execution

Usage

Executing a reset call simply sets the corresponding flags in the database

The job must be executed in order for the change to take effect

REST API Options

soft

This will preserve tracking state but prevent the use of native change detection on the next execution

More information: Job Reset | Soft

Soft Reset

PATCH {{url}}v1/jobs/{{job}}?reset=soft

permissions

This will force the re-application of permissions. Note, DataHub will not remove previously added permissions. During a permissions reset the entire hierarchy is traversed to evaluate permissions. Change detection is not used during this execution and consequently events such as deletes are not processed. However, those events will be evaluated on the following execution.

More information: Job Reset | Permissions 

Permissions Reset

PATCH {{url}}v1/jobs/{{job}}?reset=permissions

stats

This will force the transfer statistics roll-up tables to be rebuilt at the very start of the next execution

More information: Job Reset | Statistics 

Statistics Reset

PATCH {{url}}v1/jobs/{{job}}?reset=stats

Using reset options hard or full, will reset your reporting values on the Overview Transfer Details report in the DataHub User-Interface (UI)

  • This is expected since these options have reset all tracking states
  • This will not delete the job tracking data from the database

hard

This will reset all tracking state and prevent the use of native change detection on the next execution

More information: Job Reset | Hard 

Hard Reset

PATCH {{url}}v1/jobs/{{job}}?reset=hard

full (?reset=1) 

This will be a full/complete reset. It is equivalent to hard + permissions reset

More information: Job Reset | Complete / Full

Full Reset

PATCH {{url}}v1/jobs/{{job}}?reset=1

soft & start

This will reset and start a job with one call. 

Soft reset and run the job

PATCH {{url}}v1/jobs/{{job}}?reset=soft&start

Summary

The job resets related to validation inspect options allow a job execution to traverse all folders, including those that are ignored / skipped due to policy, to record information about that folder for tracking and reporting for both the source and the destination

This feature operates the Job Validation Report | item_inspection_policy

ReST API - Validation Reset Options

Options include:

inspect_filtered

This job reset will re-evaluate all filtered content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for job filters, hidden and content shared to the transfer owner

inspect_filtered

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered

inspect_shared

This job reset will re-evaluate all shared content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured to excluded data not owned by the transfer author / owner

inspect_shared

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared

inspect_all

This job reset will re-evaluate all content on the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for filters and shared

inspect_all

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all

What reset configurations align with the application user-interface?

Validation | Track Everything

1

"item_inspection_policy": "all"

will produce the same results as a

inspect_all

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all

Validation tab in the UI when both of these options are checked

  • Inspect filtered items

  • Inspect shared items

makes the same call as

inspect_all

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all

Validation tab in the UI when this item is checked

  • Inspect filtered items

makes the same call as

inspect_filtered

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered

Validation tab in the UI when this item is checked

  • Inspect shared items

makes the same call as

inspect_shared

1

PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared

User-Interface - Export Items Report

In the DataHub application, exporting the items report will have a status column where skipped content will be recorded. For each skipped entry, observe the value for the source_exists and destination_exists columns

source_exists = true

This means DataHub has identified the skipped item

destination_exists = false

This means DataHub has identified but did not transfer the item

Related Links