The Stored Logic Validity Check compiles the stored logic objects associated with a database definition and reports INVALID objects and objects that change between VALID and INVALID states as the result of a deployment. A stored logic object can become invalid for many reasons. The most common reasons are missing dependencies and syntax errors.
The CLI property to use is storedLogicValidityCheck=DISABLED | LIMITED | LOCAL | GLOBAL. The datical.project file property to use is storedLogicValidityCheck="disabled | limited | local | global".
You can see the Stored Logic Validity Check results in the Deploy reports:
Forecast operations: the validity check is not performed.
Deploy operations: the validity check is performed after deployment. You can find it in the Stored logic Validity Check section of the Deploy report.
Packager operations: the validity check is performed as part of the deployment to the
REFDB. Packager reports do not include stored logic validity check outcomes directly. The Deploy for theREFDBincludes this information and is linked in the Packager Report.
Liquibase Enterprise & Business provide the following Stored Logic Validity Check settings for the Oracle, SQL Server, and DB2 databases:
Disabled – does not perform the Stored Logic Validity Check.
Limited – checks objects that are targeted by Changesets in the deployment.
Local – checks all Stored Logic objects in all schemas included in the project or database definition.
Global – checks all Stored Logic objects in all schemas in a database, even outside the project schemas.
Using Stored Logic Validity Check: Limited Mode
The Limited mode is recommended when environments are known and expected to have a large number of stored logic objects or persistently invalid stored logic objects. In the Limited mode, DaticalDB will only compile the stored logic objects that are determined to be targeted by changes included in the deployment, which may lead to significant performance improvements for deploy operations.
However, for Oracle environments, objects that are valid after a deployment may be reported as invalid on the Deploy Report in some cases. This can occur when DaticalDB is unable to determine that the changes in the deployment are associated with the invalid object.
For this reason, it is not recommended to use storedLogicValidityAction=FAIL when storedLogicValidityCheck=LIMITED for Oracle.
The Stored Logic Validity Check workflow with the Limited mode
At the beginning of deployment, a list of all objects that are currently invalid in managed schemas is obtained.
The list is filtered based on changesets to be deployed. However, instead of compiling all invalid objects like in the Local mode, only invalid objects targeted by deployment are compiled to confirm they are invalid.
Deployment occurs.
Another compilation of objects targeted by changesets in the Deploy occurs.
The report is as follows:
If an object’s state transitions from INVALID to VALID, it is green to indicate that any issues with it were corrected.
If an object goes from VALID to INVALID, DaticalDB reports the object as INVALID and includes any relevant error messages.
DaticalDB reports on any invalid items found in the Limited mode, including objects found in another schema managed by the project and objects that were not targeted by changesets in the deployment. However, these classes of INVALID objects do not affect the Success or Failure outcome of the deployment.