Part A: Nulling the Manual Side

  1. Ensure that existing errors have been repaired.

    As mentioned earlier, you should remove the schema, restart JADE, and then reload the schema before creating fresh data.

  2. This time we will intentionally break referential integrity by using the following Workspace script to generate a different erroneous fix.

    vars
    fixLine : String;
begin
    // A product does not know its owning company
    fixLine := "FIX1: null " & Product.firstInstance.getOidString
                & " myCompany";
    write fixLine;
end;

    A consequence of this anomaly is that a 1090 exception (Attempted access via null object reference) would be raised if you attempt to reference Product::myCompany from this instance of Product.

  3. Run the erroneous repair created from the script in the previous step.

  4. Analyze the damage by running the Logical Certifier in analysis mode. This anomaly will be reported in the following way.

    *** Error 15: No inverses found for Company/2973.1‑>Company::allMyProducts (coll1=AllProductsByDescription/2976.1.2973.2.1, member=Product/2975.1) (2976.1.2973.2.1 created 01 January 1970, 12:00:00, parent 2973.1 created 17 July 2009, 14:48:39)
FIX1: remove 2976.1.2973.2.1 2975.1
CHECK: 2973.1'.asOid.getPropertyValue('allMyProducts').Object.Collection.includes('2975.1'.asOid)

The repair action to perform a remove is a consequence of the Product::myCompany reference being defined as manual, so the assumption made by the Logical Certifier is that the reference was intentionally set to null and for some reason, inverse maintenance failed and the object was not removed.