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 |
|
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 |
|
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 |
|
What reset configurations align with the application user-interface?
Validation | Track Everything
|
will produce the same results as a |
inspect_all
|
||||
Validation tab in the UI when both of these options are checked
|
makes the same call as |
inspect_all
|
||||
Validation tab in the UI when this item is checked
|
makes the same call as |
inspect_filtered
|
||||
Validation tab in the UI when this item is checked
|
makes the same call as |
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