Netravati1205
commented
9 months ago https://github.com/lansa/db-regression/pull/76 - PR for character based rules
Closed robe070 closed 9 months ago
Netravati1205
commented
9 months ago https://github.com/lansa/db-regression/pull/76 - PR for character based rules
robe070
commented
9 months ago @Netravati1205 You still need to implement the Conditional Table Trigger Points and Conditional Field Trigger Points as described above.
Ref: Table Rules and Triggers
Types of Rule
Range of Values Checks in the Technical Reference Guide
List of Values Checks in the Technical Reference Guide
Code Table Lookup Checks in the Technical Reference Guide
Simple Logic Check in the Technical Reference Guide
Complex Logic Check in the Technical Reference Guide
Date Format/Range Check in the Technical Reference Guide
Simple Rules
Character:
Simple Rules Coding Guide
VI0035C and VTLI0035C to be used for the character-based rules (7 more rules to add) Each Column will implement one Simple Rule. Use every character column type at least once. A start has been made on this Function and Table. Please complete it.
VI0035D and VTLI0035D to be used for the numeric-based rules (5 rules) Each Column will implement one Simple Rule. Use every numeric column type at least once. This is a new Function and Table. Create the Function from VI0035C. Table may be created from scratch.
VI0035E and VTLI0035E to be used for the date-based rules (5 rules) Each Column will implement one Simple Rule. Use every numeric column type at least once. This is a new Function and Table. Create the Function from VI0035C. Table may be created from scratch.
VI0035F and VTLI0035F to be used for the remaining rules (up to 5 rules) Each Column will implement one Rule. The Rules to implement will be examples of those Rules not yet covered by the Simple Rules. This is a new Function and Table. Create the Function from VI0035C. Table may be created from scratch.
Most of the Rules may be Table level Rules, like the ones already created. Ensure that 1 Rule in each Function above is implemented as a Field level Rule.
The testing is based on the message text specified in the Rule and issued when the VE occurs. One of the Rules uses a message produced in DC@M01 using the ADW0201 message with no parameters. All the other Rules use the literal message text produced by the Simple Rule generator or as specified by you, the developer, in a custom Rule.
Add each column one at a time. You will notice that in order for a subsequent column rule to be the only one issued, that all prior columns need to be set to a valid value. That should be the result of writing the test cases as provided in the example.
Triggers in the Technical Reference Guide
Trigger Points - When
The trigger point defines when the trigger should be called. A trigger may be called at many different points.
Trigger Conditions - If
Operations: GT, GE, LT, LE, EQ, NE and REF.
There are no conditions allowed for Open and Close triggers.
Note: The operation codes may have a suffix 'P', which indicates that the previous value of the nominated field should be used. The value of a previous field can only be used in 'Update' operations. REF (Refers to) is only allowed on 'Read', 'Insert' and 'Update' operations.
Trigger Functions
There are two building block application templates available, designed to form the base of a trigger function: one for field-based triggers, and one for table-based triggers
Trigger Implementation
Unconditional Table Trigger Points
One File & Trigger (VI0035G, VI0035T, VTLI0035G) to ensure all Trigger Points may be unconditionally executed. All trigger points in trigger function return an OK return code. Simply issue a message for each Trigger Point and compare the messages received to the messages expected. This has been completed
Conditional Table Trigger Points
One File & Many Trigger Functions to test trigger conditions (VI0035H, VI035xx, VTLI0035H. These do not exist. Use Unconditional trigger code as the starting point). Only the value of the column with the trigger can be tested. It fires or it does not fire. Note that the conditions GT, LT, EQ, NE can be on one Field. For example. LT 5 EQ 10 NE 11 GT 15 If value is LT 5 then that trigger would be fired and only that trigger. Note that Trigger Function always returns OK. The test is that the correct messages are issued, at the correct time, similar to Unconditional trigger testing. Values to be tested for this example would be 4, 5 (no messages), 9 (no messages), 10, 11, 15 (no messages) and 16. Every Trigger Point needs to be tested at least once (apart form Open and Close Trigger Points because they do not allow a condition to be specified. Multiple triggers firing at the same time needs to be tested too.
Each condition will require a separate Trigger Function so that the message can be individualized for the condition so it may be checked accurately. E.g. Condition LT 5 on Before Read would issue the message "BEFRED LT 5".
Each Field type will need one condition that uses another Field in the Table rather than a literal.
All Field Types must be tested for each type of condition, except for Float, Binary, VarBinary, BLOB and CLOB. Thats 12 different Field types.
Trigger Functions will need a modified naming convention so that sufficient may be created. They will be named VI035xx, starting with VI035AA for the first trigger for the first field, VI035AB for the 2nd trigger for the first field, etc.
Another Field would implement GE and LE and REF.
Conditional Field Trigger Points
One File & many Trigger Functions to test trigger conditions (VI0035I, VI035xx, VTLI0035I. These do not exist. Use Table tests above as the starting point). Very similar to the Conditional File Trigger Points. Note that all new Fields must be created in the repository so that the triggers do not effect any other test. Again a new naming convention is required. Instead of naming the Fields BIFxxxxx, name them TRGxxxxx.