Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

Example from documentation

UML diagram for example edge rule

ExampleEquivalent Example
Explanation
Code Block
languagejs
titleExample Edge Rule
collapsetrue
{
“from”: “tenant”,
“to”: “vserver”,
“label”: “owns”,
“direction”: “OUT”,
“multiplicity”: “One2Many”,
“contains-other-v”: “${direction}”,
“delete-other-v”: “NONE”,
“SVC-INFRA”: “!${direction}”,
“prevent-delete”: “${direction}”
}
Code Block
languagejs
titleEquivalent
Example
Edge Rule
collapsetrue
{
“from”: “vserver”,
“to”: “tenant”,
“label”: “owns”,
“direction”: “IN”,
“multiplicity”: 
“Many2One”
“One2Many”,
“contains-other-v”: “!${direction}”,
“delete-other-v”: “NONE”,
“SVC-INFRA”: “${direction}”,
“prevent-delete”: “!${direction}”
}
Code Block
languagetext
titleHow to read in/out/direction
collapsetrue
How to read "from"/"to" and "direction" in this case:
- the "in" node is "vserver"
- the "out" node is "tenant"

Code Block
languagetext
titleHow to read the label
collapsetrue
How to read the "label" in this case:
- ("out" node) "label" ("in" node)

i.e. tenant "owns" vserver

Code Block
languagetext
titleHow to read multiplicity
collapsetrue
How to read "multiplicity" in this case:
- ("in" node) cardinality is "one"
- ("out" node) cardinality is "many"

i.e.
Each "tenant" has one "vserver"
if "vserver" is deleted, nothing is done to "tenant"

Each "vserver" has many "tenants"

Code Block
languagetext
  • "tenant" cannot be deleted if related to "vserver"
  • titleHow to read contains-other-v
    collapsetrue
    How to read "contains-other-v" in this case:
    - fetching data for ("out" node) includes data for ("in" node)
    
    i.e. fetching data for "tenant" includes data for "vserver"
    
    
    Code Block
    languagetext
    titleHow to read delete-other-v
    collapsetrue
    How to read "delete-other-v" in this case:
    - delete of ("out" node) includes does nothing to ("in" node)
    
    i.e. delete of "tenant" includes does nothing to "vserver"
    
    
    Code Block
    languagetext
    titleHow to read SVC-INFRA
    collapsetrue
    How to read "SVC-INFRA" in this case:
    - when running edge-tag-query on ("in" node) traverse to ("out" node) and continue
    
    i.e.
    when running edge-tag-query on "vserver" traverse to "tenant" and continue
    
    
    Code Block
    languagetext
    titleHow to read prevent-delete
    collapsetrue
    How to read "prevent-delete" in this case:
    - prevent delete of ("out" node) when related to ("in" node), allow delete of ("in" node)
    
    i.e.
    prevent delete of "tenant" when related to "vserver", allow delete of "vserver"
    
    


    General Applicability

    • EdgeRules only apply to "relationship-list" relations in the schema, since the referenced object could be anything
    • EdgeRules do no not apply to sub-component relations in the schema, since this is implicit and hard-coded behaviour

    ...

    FieldValuesNotes
    from

    (literal string as entered in EdgeRule file)


    Expected to match the "name" value of "xml-root-element" in OXM file.

    Note that the "from|to" pair is normalised in the code according to alphabetical order, so that "cousin pairs" with the "to|from" ordering in the EdgeRule are also grouped together, e.g.

    • from "l-interface" to "logical-link" → "l-interface|logical-link"
    • from "logical-link" to "l-interface" → "l-interface|logical-link"

    Also note that the hyphens "-" are removed from the names before comparison, so the following would be equivalent:

    • l-interface
    • linter-face
    to

    (literal string as entered in EdgeRule file)


    Expected to match the "name" value of "xml-root-element" in OXM file.

    Note that the "from|to" pair is normalised in the code according to alphabetical order, so that "cousin pairs" with the "to|from" ordering in the EdgeRule are also grouped together, e.g.

    • from "l-interface" to "logical-link" → "l-interface|logical-link"
    • from "logical-link" to "l-interface" → "l-interface|logical-link"

    Also note that the hyphens "-" are removed from the names before comparison, so the following would be equivalent:

    • l-interface
    • linter-face
    label

    (literal string as entered in EdgeRule file)


    By convention, appears to be one of:

    • isA

    • org.onap.relationships.inventory.AppliesTo

    • org.onap.relationships.inventory.BelongsTo

    • org.onap.relationships.inventory.BridgedTo

    • org.onap.relationships.inventory.ComposedOf

    • org.onap.relationships.inventory.DependsOn

    • org.onap.relationships.inventory.Destination

    • org.onap.relationships.inventory.ForwardsTo

    • org.onap.relationships.inventory.IsA

    • org.onap.relationships.inventory.LocatedIn

    • org.onap.relationships.inventory.MemberOf

    • org.onap.relationships.inventory.network.MemberOf

    • org.onap.relationships.inventory.PartOf

    • org.onap.relationships.inventory.Source

    • org.onap.relationships.inventory.Targets

    • org.onap.relationships.inventory.Uses

    • startsWith

    • tosca.relationships.AttachesTo

    • tosca.relationships.HostedOn

    • tosca.relationships.network.BindsTo

    • tosca.relationships.network.LinksTo

    direction
    • IN
    • OUT
    • NONE (default value used when Tinkerpop Direction is null)
    • BOTH (default value used when string is unrecognised)

    Based on and extended from https://tinkerpop.apache.org/javadocs/3.3.2/core/org/apache/tinkerpop/gremlin/structure/Direction.html

    Comparison is case-sensitive

    multiplicity
    • Many2Many
    • One2Many
    • One2One
    • Many2One (default value used when string is unrecognised)
    Comparison ignores case
    contains-other-v
    • IN
    • OUT
    • BOTH
    • NONE
    • ${direction}
    • !${direction}

    This is an "edge property" that applies for specific traversal directionsto the other vertex.

    Comparison is case-sensitive

    Note that "opposite" means:

    • IN → OUT
    • OUT → IN
    • BOTH → BOTH
    • NONE → BOTH


    delete-other-v
    • IN
    • OUT
    • BOTH
    • NONE
    • ${direction}
    • !${direction}

    This is an "edge property" that applies for specific traversal directionsto the other vertex.

    Comparison is case-sensitive

    Note that "opposite" means:

    • IN → OUT
    • OUT → IN
    • BOTH → BOTH
    • NONE → BOTH
    SVC-INFRA
    • IN
    • OUT
    • BOTH
    • NONE
    • ${direction}
    • !${direction}

    This is an "edge property" that applies for specific traversal directionsto the other vertex.

    Comparison is case-sensitive

    Note that "opposite" means:

    • IN → OUT
    • OUT → IN
    • BOTH → BOTH
    • NONE → BOTH
    prevent-delete
    • IN
    • OUT
    • BOTH
    • NONE
    • ${direction}
    • !${direction}

    This is an "edge property" that applies for specific traversal directionsto the other vertex.

    Comparison is case-sensitive

    Note that "opposite" means:

    • IN → OUT
    • OUT → IN
    • BOTH → BOTH
    • NONE → BOTH
    default
    • true
    • false (default value used when string is unrecognised)


    Default EdgeRule will apply when no other more specific rule applies ?

    Based on https://docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html#valueOf(java.lang.String)

    Comparison ignores case

    description

    (literal string as entered in EdgeRule file)


    Optional for backwards compatibility with v12 and earlier (default value is empty string)

    The EdgeRule JSON format does not permit comments (presence of comments appears to make the parser skip entries in the file).

    Questions

    1. Is there a way to find/remove the unused/redundant EdgeRules from the json file?
    2. Is there any plan to simplify EdgeRules into an unambiguous canonical form (might be easier to read and write correctly)?
    3. How does the "default" property actually work? In v13, there are 226 EdgeRules with 224 having default "true" and 2 having default "false".