Obsolete COSMOS SDD Tooling BTG Rules

This design has been deprecated as we have gone away from the rules engine. Our new design is located here COSMOS SDD Tooling BTG Data Type Comparisons

This page holds ideas about how rules should be written for combining two SDDs together.

Rules

Our rules engine is Drools 4.0.4. When dealing with rules, we need to take into consideration the following:

• We have no control over when a comparison could be made and a rule fires
• I'm sure there's more, please fill in other bullets.

Resources

Resources can have any number of hosted resources, and those hosted resources can have any number of hosted resources, and etc. We need some rules to determine how to combine two trees from different descriptors.

Let's say we have the following two resource trees:

Tree 1:

A
  B
    C
  D
  E
H
  G

Tree 2:

F
  A
    B
      C
  G

The same letters in different trees refer to the same resource and should be merge together when merging trees.

Since we don't know the order resources are compared, we need to write the rules in a way that order doesn't matter. Our rules for merging are the following:

1. Merge two matching resources when at least one of the resources has a parent that is not a resource.
   • If the resources are in different trees, the ancestry (parent resource and up) should be left in tact. Meaning, the resource with no parent will now have the same parent as the matching resource in the other tree. The resource with no parent will be removed from the root of the tree and merge in the tree with the resource that has a parent.
   • (This may not happen with the current rules) If the resources are in the same tree, the resource with no parent will be removed from the root of the tree and merged with the resource that has a parent.
   • If both matching resources do not have parent resources, then the resource from one of the trees will be removed and merged with the other.
   • During merging, the children of both objects will simply be copied in place to be handled by the second rule.
2. If two matching resources have the same parent in the same tree, then merge them.
   • During merging, the children of both object will simply be copied in place to be handled by another firing of this rule.

Taking the two trees above, here is one possible case of merging: (A lowercase m is used to indicate two matching resources that have been merged. A number indicates the tree that a resource has originated from.)

Merging of resource A

Both A resources are merged into tree 2. Resource A's children are brought along and copied in place. A is then removed from tree 1.

Tree 1:

H
  G

Tree 2:

F
  Am
    B
      C
    B1
      C1
    D1
    E1
  G

Merging of resources without parents

Both H and F resources don't have parents that are resources. This means the entire resource can be copied to the root of the other tree. We will copy F to tree 1. Tree 2 is now empty.

Tree 1:

H
  G
F2
  Am
    B2
      C2
    B1
      C1
    D1
    E1
  G2

Tree 2:

Merging of resource B

The B resources have the same parent. We will merge the B resources and copy the rest of the tree in place.

Tree 1:

H
  G
F2
  Am
    Bm
      C2
      C1
    D1
    E1
  G2

Merging of resource C

The C resources have the same parent. We will merge the C resources.

Tree 1:

H
  G
F2
  Am
    Bm
      Cm
    D1
    E1
  G2

We now have the final merged tree. The G resources don't get merged since they exist under different parents.

Problems to be solved

How to merge hierarchies of different types

Let's say we have the following trees:

Tree1:

A
  B
    C
    D

Tree2:

A
  B
    C

All four are different types. If we try to merge C first, we have to know which B it's currently under and if those B types are the same. If we merge tree 1's B type into tree 2, we still need to keep B around since it contains C and D. We need to wait for those rules to merge them since having multiple C types under B might not be allowed by the schema, so they can't be copied in place like Resources can.

Here are three separate solutions we talked about on 1/30:

1. Compute all lineage up front:
   • The wrapper object contains a method to compute and store the lineage.
   • The lineage of the data object is computed before being put into working memory.
   • The lineage is represented by a unique hash.
   • The lineage is compared to determine if objects should be merged.
   • The lineage is recomputed for objects that have been merged and their children.
2. Compute lineage on the fly and cache results:
   • The wrapper object contains a method to compute and store the lineage.
   • During data object comparison, the lineage is computed if it doesn't exist.
   • The lineage is represented by a unique hash.
   • The lineage is compared to determine if objects should be merged.
   • The lineage is recomputed for objects that have been merged and their children.
3. Check whether or not the parent has been merged:
   • The wrapper object contains class variables to keep track of merge status and the object it has been merged with.
   • During data object comparison:
     • Merge status is checked.
       • If both have already been merged, then skip.
       • If one or both have not been merged, then merge and set the merge flag.
     • Parent merge status is checked:
       • If parents have not been merged, then we can't merge these things yet.
       • If parents have been merged:
         • If parents have been merged with each other, then merge.
         • If parents have not been merged with each other, then don't merge.
   • Must keep track of all objects merged together.
   • Must make the same changes across all trees.

We walked away thinking that a mixture of the second and third would be of most use. We need to consider the potential that lineage calculations are very expensive and would like to do those as infrequently as possible.

Performance enhancement possibility:

• split rules into groups to control which get fired first