Update models

- update docker compose to use new generated sql script - update cloud event example Issue-ID: SMO-160 Change-Id: I02d508c86ead1e1991e4b1dc2e13593890b67c7a Signed-off-by: JvD_Ericsson <[email protected]>
o-ran-sc · Jul 15, 2024 · 84d3ba8 · 84d3ba8
1 parent 3a4310c
commit 84d3ba8
Show file tree

Hide file tree

Showing 14 changed files with 1,313 additions and 1,871 deletions.
diff --git a/docker-compose/cloudEventProducer/events/cloudEventExampleMerge.txt b/docker-compose/cloudEventProducer/events/cloudEventExampleMerge.txt
diff --git a/docker-compose/sql_scripts/00_init-teiv-exposure-model.sql b/docker-compose/sql_scripts/00_init-teiv-exposure-model.sql
diff --git a/docker-compose/sql_scripts/01_init-teiv-exposure-data.sql b/docker-compose/sql_scripts/01_init-teiv-exposure-data.sql
diff --git a/...l-schema-generator/src/main/java/org/oran/smo/teiv/pgsqlgenerator/YangModelProcessor.java b/...l-schema-generator/src/main/java/org/oran/smo/teiv/pgsqlgenerator/YangModelProcessor.java
@@ -92,6 +92,7 @@ private HashMap<String, String> createDataTypeMapping() {
             {
                 put("string", TEXT);
                 put("uint32", BIGINT);
+                put("int32", BIGINT);
                 put("or-teiv-types:_3GPP_FDN_Type", TEXT);
                 put("enumeration", TEXT);
                 put("types3gpp:PLMNId", JSONB);
@@ -100,6 +101,7 @@ private HashMap<String, String> createDataTypeMapping() {
                 put("[uses types3gpp:PLMNId]", JSONB);
                 put("geo:geo-location", "geography");
                 put("uint64", BIGINT);
+                put("int64", BIGINT);
                 put("decimal64", DECIMAL);
                 put("[uses or-teiv-types:CM_ID]", JSONB);
             }

diff --git a/teiv/src/main/resources/models/o-ran-smo-teiv-common-yang-extensions.yang b/teiv/src/main/resources/models/o-ran-smo-teiv-common-yang-extensions.yang
@@ -29,115 +29,126 @@ module o-ran-smo-teiv-common-yang-extensions {
 
   SPDX-License-Identifier: Apache-2.0";
 
-  revision "2024-05-02" {
-    description "Initial revision.";
-    or-teiv-yext:label 0.3.0;
-  }
-
-  extension biDirectionalTopologyRelationship {
-
-    description
-      "Defines a bi-directional relationship in the topology.
-
-       A bi-directional-association (BDA) is a relationship comprising of an
-       A-side and a B-side. The A-side is considered the originating side of
-       the relationship; the B-side is considered the terminating side of the
-       relationship. The order of A-side and B-side is of importance and MUST
-       NOT be changed once defined.
-
-       Both A-side and B-side are defined on a type, and are given a role. A
-       type may have multiple originating and/or terminating sides of a
-       relationship, all distinguished by role name.
-
-       The statement MUST only be a substatement of the 'module' statement.
-       Multiple 'bi-directional-topology-relationship' statements are allowed
-       per parent statement.
-
-       Substatements to the 'bi-directional-topology-relationship' define the
-       A-side and the B-side, respectively, and optionally properties of the
-       relationship. Data nodes of types 'leaf' and 'leaf-list' are used for
-       this purpose. One of the data nodes MUST be annotated with the 'a-side'
-       extension; another data node MUST be annotated with the 'b-side'
-       extension. Other data nodes define properties of the relationship.
-
-       The argument is the name of the relationship. The relationship name is
-       scoped to the namespace of the declaring module and MUST be unique
-       within the scope.";
-
-    argument relationshipName;
-  }
-
-  extension aSide {
-    description
-      "Defines the A-side of a relationship.
-
-       The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
-       statement, which itself must be a substatement of the
-       'uni-directional-topology-relationship' statement.
-
-       The data type of the parent 'leaf' or 'leaf-list' MUST be
-       'instance-identifier'. Constraints MAY be used as part of the parent
-       'leaf' or 'leaf-list' to enforce cardinality.
-
-       The identifier of the parent 'leaf' or 'leaf-list' is used as name of
-       the role of the A-side of the relationship. The name of the role is
-       scoped to the type on which the A-side is defined and MUST be unique
-       within the scope.
-
-       While the parent 'leaf' or 'leaf-list' does not result in a property of
-       the relationship, it is RECOMMENDED to avoid using the name of an
-       existing type property as role name to avoid potential ambiguities
-       between properties of a type, and roles of a relationship on the type.
-
-       The argument is the name of the type on which the A-side resides. If the
-       type is declared in another module, the type must be prefixed, and a
-       corresponding 'import' statement be used to declare the prefix.";
-
-    argument aSideType;
-  }
-
-  extension bSide {
-    description "Defines the B-side of a relationship.
-
-       The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
-       statement, which itself must be a substatement of the
-       'uni-directional-topology-relationship' statement.
-
-       The data type of the parent 'leaf' or 'leaf-list' MUST be
-       'instance-identifier'. Constraints MAY be used as part of the parent
-       'leaf' or 'leaf-list' to enforce cardinality.
-
-       The identifier of the parent 'leaf' or 'leaf-list' is used as name of
-       the role of the B-side of the relationship. The name of the role is
-       scoped to the type on which the B-side is defined and MUST be unique
-       within the scope.
-
-       While the parent 'leaf' or 'leaf-list' does not result in a property of
-       the relationship, it is RECOMMENDED to avoid using the name of an
-       existing type property as role name to avoid potential ambiguities
-       between properties of a type, and roles of a relationship on the type.
-
-       The argument is the name of the type on which the B-side resides. If the
-       type is declared in another module, the type must be prefixed, and a
-       corresponding 'import' statement be used to declare the prefix.";
-
-    argument bSideType;
-  }
-
-  extension domain {
-    description "Keyword used to carry domain information.";
-    argument domainName;
-  }
-
-  extension label {
-    description "The label can be used to give modules and submodules a semantic version, in addition to their revision.
-
-      The format of the label is 'x.y.z' - expressed as pattern, it is [0-9]+\\.[0-9]+\\.[0-9]+
-
-      The statement MUST only be a substatement of the revision statement.  Zero or one revision label statements
-      per parent statement are allowed.
-
-      Revision labels MUST be unique amongst all revisions of a module or submodule.";
-      argument semversion;
-  }
+    revision "2024-05-24" {
+        description "Initial revision.";
+        or-teiv-yext:label 0.3.0;
+    }
+
+    extension biDirectionalTopologyRelationship {
+        description
+            "Defines a bi-directional relationship in the topology.
+
+            A bi-directional-association (BDA) is a relationship comprising of
+            an A-side and a B-side. The A-side is considered the originating
+            side of the relationship; the B-side is considered the terminating
+            side of the relationship. The order of A-side and B-side is of
+            importance and MUST NOT be changed once defined.
+
+            Both A-side and B-side are defined on a type, and are given a role.
+            A type may have multiple originating and/or terminating sides of a
+            relationship, all distinguished by role name.
+
+            The statement MUST only be a substatement of the 'module' statement.
+            Multiple 'bi-directional-topology-relationship' statements are
+            allowed per parent statement.
+
+            Substatements to the 'bi-directional-topology-relationship' define
+            the A-side and the B-side, respectively, and optionally properties
+            of the relationship. Data nodes of types 'leaf' and 'leaf-list' are
+            used for this purpose. One of the data nodes MUST be annotated with
+            the 'a-side' extension; another data node MUST be annotated with the
+            'b-side' extension. Other data nodes define properties of the
+            relationship.
+
+            The argument is the name of the relationship. The relationship name
+            is scoped to the namespace of the declaring module and MUST be
+            unique within the scope.";
+
+        argument relationshipName;
+    }
+
+    extension aSide {
+        description
+            "Defines the A-side of a relationship.
+
+            The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
+            statement, which itself must be a substatement of the
+            'uni-directional-topology-relationship' statement.
+
+            The data type of the parent 'leaf' or 'leaf-list' MUST be
+            'instance-identifier'. Constraints MAY be used as part of the parent
+            'leaf' or 'leaf-list' to enforce cardinality.
+
+            The identifier of the parent 'leaf' or 'leaf-list' is used as name
+            of the role of the A-side of the relationship. The name of the role
+            is scoped to the type on which the A-side is defined and MUST be
+            unique within the scope.
+
+            While the parent 'leaf' or 'leaf-list' does not result in a property
+            of the relationship, it is RECOMMENDED to avoid using the name of an
+            existing type property as role name to avoid potential ambiguities
+            between properties of a type, and roles of a relationship on the
+            type.
+
+            The argument is the name of the type on which the A-side resides.
+            If the type is declared in another module, the type must be
+            prefixed, and a corresponding 'import' statement be used to declare
+            the prefix.";
+
+        argument aSideType;
+    }
+
+    extension bSide {
+        description
+            "Defines the B-side of a relationship.
+
+            The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
+            statement, which itself must be a substatement of the
+            'uni-directional-topology-relationship' statement.
+
+            The data type of the parent 'leaf' or 'leaf-list' MUST be
+            'instance-identifier'. Constraints MAY be used as part of the parent
+            'leaf' or 'leaf-list' to enforce cardinality.
+
+            The identifier of the parent 'leaf' or 'leaf-list' is used as name
+            of the role of the B-side of the relationship. The name of the role
+            is scoped to the type on which the B-side is defined and MUST be
+            unique within the scope.
+
+            While the parent 'leaf' or 'leaf-list' does not result in a property
+            of the relationship, it is RECOMMENDED to avoid using the name of an
+            existing type property as role name to avoid potential ambiguities
+            between properties of a type, and roles of a relationship on the
+            type.
+
+            The argument is the name of the type on which the B-side resides.
+            If the type is declared in another module, the type must be
+            prefixed, and a corresponding 'import' statement be used to declare
+            the prefix.";
+
+        argument bSideType;
+    }
+
+    extension domain {
+        description "Keyword used to carry domain information.";
+        argument domainName;
+    }
+
+    extension label {
+        description
+            "The label can be used to give modules and submodules a semantic
+            version, in addition to their revision.
+
+            The format of the label is 'x.y.z' - expressed as pattern, it is
+            [0-9]+\\.[0-9]+\\.[0-9]+
+
+            The statement MUST only be a substatement of the revision statement.
+            Zero or one revision label statements per parent statement are
+            allowed.
+
+            Revision labels MUST be unique amongst all revisions of a module or
+            submodule.";
+
+        argument semversion;
+    }
 }