Skip to content

Data Validity

Data Validity provides modeling support for restricting the usage of data records based on their validity. The restriction is applied through LOV filtering in the client and reference checking in the PL/SQL server.

The section describes only about the server side development.

  • Overview
  • Validity Types
  • Examples
  • Avoiding Validity Checks
  • Impact of Indroducing Validity
  • Developer Studio References

Overview

Validity is implemented as an extension to the existing referential integrity concept in PL/SQL server which is centered around the "Exist" method. If validity is enabled for a particular entity, its corresponding "Exist" method will check for the validity of a record as well in addition to the availability in the table.

Validity Types

The Validity of an entity can be modeled in two flavors.

  1. States
  2. Interval

States

There are three different states a validity of a data record can take.

  • Active     - The record can be accessed as usual.
  • Hidden    - The record won't show up for usage in the client LOV by default. But on the server side, no restrictions for usage.
  • Blocked  - The record cannot be used anyway and won't show up in the client. Server method will throw an exception when trying to use a blocked record.

There are three combinations of these states that can be used to model an entity which determines the availability of each of these states.

The combinations are ActiveHiddenBlocked, ActiveBlocked and ActiveHidden. When one of these 'validity' modes are used, the code generator will create a state machine behind the scenes to provide the state transition functionality. This means that it is not possible to add another state machine in to a model which is having a states based validity and vice versa.

Example Syntax:

  • validity ActiveHiddenBlocked;

Interval

The only option available currently for an interval based validity is DateInterval

An entity with DateInterval validity will have a "FROM DATE" and a "TO DATE" which specifies the date range a particular record is valid in. That date range is compared against a reference date ( see Example 1 ) at the time of validity checking. If the supplied value doesn't fall under the specified interval, the record will be considered blocked for usage and exception is thrown.

Example Syntax:

  • validity DateInterval;    - Framework generated columns is used to store from date and to date.
  • validity DateInterval{

FromColumn "VALID_FROM";

ToColumn "VALID_UNTIL";

}                                - Existing columns can be mapped as from date and to date.

Important - At development time, make sure to refresh the dictionary cache after the server modeling.

Example 1

DemoSalesOrder has associations to DemoDeliveryPerson and DemoDiscountType. DemoDeliveryPerson has an 'ActiveHiddenBlocked' validity configuration which means a DemoDeliveryPerson can be made Active, Hidden or Blocked. Whereas a DemoDiscountType is valid only for the specified date range specified for that particular record. Shown below is how we can model this scenario in the server.

Server Modeling

ValidityIntervalRefColumn is stated to check against the date range. The database column name has to be stated here (not the entity attribute). This has to be a Date type column.

Generated Code

In the referred entities, the Exist method is changed to consider the validity. A view comment attribute is also added.

Demo_Delivery_Person_API

Demo_Discount_Type_API

In the referring entity, the Check_Common___ implementation method is changed. For the references to DateInterval validity entities, a column comment is added to state the validity interval reference column.

Demo_Sales_Order_API

Avoiding Validity Checks

It is possible to model the references so that the reference checks done in the "Check_Common___" method will skip to check for validity. This may be useful in modeling archive type entities.

Impact of Introducing Validity

When "Validity" is introduced, the "Exist" method behavior of the corresponding API changes. This change may affect the calls to that method in anywhere in the code. Any such call is impacted by the validity of the particular record it is referring. This has to be anticipated in the usages of such an "Exist" method.

Based on the application requirements either the code should specify the proper conditions to make the call to "Exist" method,

Or it should skip the validity check from the "Exist" call.