Application Validation Checks

Overview

System validations check the internal consistency of data stored in the Metadata Management Module (MMM) database. In an ideal state, there are no inconsistencies in the MMM data. However, inconsistencies can be created under some circumstances, such as concurrent deletion of the same metadata node.

System validations are accessible for admin users at <ONE_URL>/organization/application/validations.

To run validation checks, you need the MMM_admin identity provider role.

You can view the recently run validations in any application mode in Global Settings > Validations in the Maintenance Center section.

Run validations

To run all validation checks, select Run all validations on the Validations screen. To run only one group of validators, select the arrow next to the option and choose the group:

Validation options

In the Run all validations menu, in addition to All validators, you can choose from the following validations:

System tables validators: Check pre-computed permission tables and dictionary tables storing type and path names as numbers.
Node tables validators: Check content of system columns of the data tables. For example, they check that parent_id_i is not null and many other system column validations.
Computed content validators: Check if computed content nodes have correct SQL syntax.
Tables schema validators: Check if the tables generated by MMM have the expected definition.
Application validations validators: Check all PUBLISHED data stored in the MMM to ensure they satisfy the schema. These are the same constraint checks that MMM applies on every publish and at the end of every metadata import, but they cover all published nodes of each node type. For example, they check if references point to existing nodes, if required properties have non-null values and if nodes are unique.

Running all validations might take a long time to complete, depending on the database size.

View validation run results

The Validation Runs tab lists both the runs started manually and the scheduled runs. By default, scheduled runs of all validators start on weekend nights.

After the validation checks are complete, you can see the results on the Validation Runs tab. In Info, the status of the validation run and its start and end time are shown.

Validation run states

A validation run can end in the following states:

FINISHED: Validation run finished.
- White row: No inconsistencies found.
- Red row: Inconsistencies found.
ABORTED: Execution canceled, probably by a user.
FAILED: The run failed due to an unexpected error.

View all validations or the failed validations only (if there are any) by filtering the checks:

The Validation Checks section shows all performed validations with their status and error count:

Expand the validation groups to see each validation result:

Validation categories

Under the node node, there are two main categories of validations:

Internal validations: Check for issues such as null system columns. Display one metadata node ID per row.
Application validations: Check that PUBLISHED nodes satisfy the schema constraints:
- Property is required
- Reference missing
- Unique constraint is violated

The two validation types display results in different formats. Internal validations list each affected metadata node on a separate row. Application validations group all affected nodes together by the constraint they violated, showing the list of IDs followed by the constraint details.

Understanding error messages

When you expand an erroneous validation, the red rows show IDs of erroneous nodes followed by a message.

Application validation errors

Application validations display errors grouped by constraint violations:

For example:

[UId(15bbce34-0000-7000-0000-000000161e90), UId(15bbce34-0000-7000-0000-0000001981f0), UId(36ed325c-0000-7000-0000-0000008b8d91)]:
DbPublishValidationsSession.PublishConstraintViolationGroupingKey(constraintId=PARENT_EXISTS,
nodePath=NodePath(path=/sources/workspace/catalogItems/profilingConfigurationInstances/profiles/anomalyState),
constraintType=PARENT_EXISTS, code=PARENT_DOES_NOT_EXIST, entityName=anomalyState, propertyName=null, propertyNames=null)

In this example, the entity anomalyState does not have a parent. The IDs show the exact metadata nodes that are missing parent nodes.

The list of IDs can be duplicated. For the same entity, there can be multiple node paths. To get a unique set of affected nodes, collect all IDs and deduplicate them.

Internal validation errors

Internal validations display one error per row with the error message and affected node ID:

Resolve errors

If the validation runs fail, expand the validation to see the error message.

If errors are found in validations for precomputed data stored in _q tables, you can recalculate the ancestors using the following GraphQL mutation:
```
mutation {
  _recalculateAncestors
}
```
If errors are found in other validations, the issues are in the database itself. Follow the error message to resolve the issue.

For example, for missing parent errors such as anomalyState, select Fix validation issues on the validation run to delete the orphaned nodes. See Fix Validation Issues Automatically. Alternatively, delete and publish the entities using GraphQL mutations.

GraphQL API for system validations

You can access and manage system validations through the GraphQL API. For more information about using GraphQL in ONE, see ONE API.

Query validation runs

Retrieve the most recent validation run with errors:

query e {
  _systemValidationRuns(size: 1, withErrorsOnly: true) {
    edges {
      node {
        errorsCount
        start
        status
        id
        checks {
          edges {
            node {
              id
              errorMessage
              distinctErrorsCount
              validator {
                name
              }
            }
          }
        }
      }
    }
  }
}

Query validation errors

Retrieve detailed error information for a specific validation check:

query e1 {
  _systemValidationErrors(runId: "4155c8b9-0000-7000-0000-000000201aa0", checkId: "4155c8b9-0000-7000-0000-000000201b0b") {
    edges {
      node {
        message
        record
        checkId
      }
    }
  }
}

Replace runId and checkId with the appropriate values from your validation run.

Delete and stop validation runs

You can delete a finished validation run and stop the running one.

To delete the old validation run, hover over the run and select the bin icon:
To stop the running validation, hover over the run and select the cross icon:

Was this page useful?