Profile io.ucaiug.cimtool.generated String abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ private ; return ; this. = ; package ; import jakarta.persistence.*; import java.time.*; import java.util.*; Annotated Java for the profile. Generated by CIMTool https://cimtool.ucaiug.io JPA Version: Jakarta Persistence 3.1 (Jakarta EE 10) All entity hierarchies use JOINED table-per-type inheritance, matching the SQL DDL schema generated by the companion sql-rdfs-ansi92 builder. Each class maps to its own table joined on the primary key. Entity classes and the allClasses array are emitted in inheritance-safe topological order using Kahn's algorithm, ensuring every superclass appears before its subclasses. EnumeratedTypes are always emitted first as they have no dependencies. ComplexType and Root classes follow in inheritance-sorted order. Note: only the SuperType (inheritance) chain is used for ordering — FK associations are intentionally excluded. Java allows forward class references within a single compilation unit, so FK association order is irrelevant for class declarations. Including FK associations in the dependency graph creates cycles in profiles with dense association networks (e.g. CGMES) that cause 40+ classes to fall back to document order — precisely the problem this sort is designed to prevent. Classes that inherit from IdentifiedObject use a natural String mRID primary key mapped to @Id @Column(name="mRID"). Classes that do NOT inherit from IdentifiedObject (e.g. CurveData, TapChangerTablePoint, Quality61850) use a surrogate UUID primary key mapped to @Id @GeneratedValue(strategy=GenerationType.UUID) with @Column(name="id"). The UUID is auto-generated by the JPA provider on persist, consistent with the companion SQL DDL schema. All single-valued FK associations (a:Instance, a:Reference, a:Compound) receive a corresponding @Index entry on the @Table annotation. This mirrors exactly the CREATE INDEX statements emitted by the companion sql-rdfs-ansi92 builder, using the same naming convention: ix_{tableName}_{columnName} CREATE INDEX ix_Equipment_EquipmentContainer ... @Index(name="ix_Equipment_EquipmentContainer", columnList="EquipmentContainer") Consistent naming ensures schema validation (hbm2ddl.auto=validate) finds the expected index names in the database. Compound FK columns are also indexed even though they already carry a UNIQUE constraint — this maintains exact parity with the SQL DDL builder. Non-IdentifiedObject entity classes (those using a surrogate UUID @Id) receive a @UniqueConstraint on their @Table annotation spanning all required (minOccurs=1) non-surrogate columns — both scalar attributes and required single-valued FK associations. This mirrors the heuristic UNIQUE constraint emitted by the companion sql-rdfs-ansi92 builder: ALTER TABLE "CurveData" ADD UNIQUE ("xvalue", "y1value", "Curve"); @UniqueConstraint(columnNames = {"xvalue", "y1value", "Curve"}) The constraint may be wider than the true natural key (which is only known from the IEC specification prose, not from the profile catalog XML) but is never incorrect — a wider UNIQUE prevents valid duplicate insertion; a missing UNIQUE permits silent semantic corruption. IdentifiedObject subclasses are not affected — their natural mRID PK is the authoritative unique identifier and needs no additional guard. CIM boolean attributes (xstype="boolean") map to Java Boolean and are annotated with @Column(columnDefinition="INTEGER DEFAULT 0"). Without this hint most JPA providers create a BOOLEAN or BIT column, which does not match the companion sql-rdfs-ansi92 builder's schema: "enabled" INTEGER DEFAULT 0 CHECK ("enabled" IN (0, 1)) The columnDefinition aligns the JPA-managed schema with the SQL DDL. Required booleans (minOccurs=1) additionally carry nullable=false, matching the NOT NULL emitted by the SQL DDL builder for those columns. Oracle portability note: columnDefinition="INTEGER DEFAULT 0" is passed verbatim to the RDBMS during JPA schema generation. On Oracle, INTEGER maps to NUMBER(38) rather than the idiomatic NUMBER(1). If targeting Oracle and using JPA schema generation, override columnDefinition to NUMBER(1) DEFAULT 0 in a subclass or use a custom AttributeConverter. This concern does not apply when using the companion sql-rdfs-ansi92 DDL script for schema creation (the recommended approach) — in that case the columnDefinition hint is advisory only and never executed. All entity classes include generated equals() and hashCode() implementations following the Mihalcea portable JPA pattern: - equals() uses getClass() rather than instanceof to correctly handle Hibernate proxy objects. instanceof would pass for the proxy-to-real direction but fail in reverse, causing subtle bugs when entities are stored in collections. - hashCode() returns getClass().hashCode() — a fixed constant per class. This ensures hash stability across the transient-to- persistent lifecycle before the JPA provider assigns the key. - equals() compares on the natural key only when non-null, so two unsaved (transient) instances are never considered equal. - IdentifiedObject root: key = mRID (String) - Non-IdentifiedObject roots: key = id (UUID) - CompoundType classes: key = id (UUID) - EnumeratedType classes: key = name (String) Reference: Vlad Mihalcea, "The Best Way to Implement equals and hashCode with JPA": https://vladmihalcea.com/how-to-implement-equals-and-hashcode-using-the-jpa-entity-identifier/ The @Inheritance(strategy=InheritanceType.JOINED) annotation is only emitted on non-IdentifiedObject root classes that have at least one subclass present in this profile. Leaf classes with no subclasses (e.g. CurveData, RegularTimePoint) are emitted without @Inheritance — it would be misleading to the JPA provider and adds no functional value for a class that is never extended. IdentifiedObject is always emitted with @Inheritance since it is by definition the root of the entire entity hierarchy. Collection associations (maxOccurs=unbounded, i.e. the one side of a one-to-many relationship) are intentionally NOT mapped as @OneToMany. The @ManyToOne on the child side is sufficient for all JPA operations. This is a deliberate architectural choice, not an omission. Developers who expect @OneToMany collection properties should read this section before adding them manually. Rationale: - @OneToMany requires a mappedBy string that is not validated at compile time. A mismatch fails silently and throws an obscure AnnotationException at JPA provider bootstrap, which is difficult to diagnose in generated code. - CIM associations are unbounded by definition. Loading an unbounded collection into memory with no pagination is a runtime hazard for large profiles such as CGMES CoreEquipment, where an equipment container may have thousands of children. Hibernate will issue a single SELECT with no LIMIT, materialising the entire result set. - Bidirectional @OneToMany requires both sides to be kept in sync on every add and remove operation. Failing to do so causes inconsistent in-memory state and subtle persistence bugs that are notoriously difficult to reproduce and debug. - Bidirectional mappings with CascadeType.ALL or orphanRemoval=true interact unpredictably with the compound value object cascade semantics already present in this generated code, risking accidental deletion of entities that should remain. - Inverse associations are profile-dependent and not present in all profiles, making generated @OneToMany properties inconsistent across profiles and creating a false expectation of completeness. - Explicit JPQL queries support pagination, filtering, and sorting that a generated collection property never can, and make the data access intent explicit rather than implicit. To navigate from a parent entity to its children, use a JPQL query. Query through the child side via the @ManyToOne FK field. This keeps all data access explicit, pageable, and safe for large result sets: // Find all PowerElectronicsUnit instances for a given connection: "SELECT u FROM PowerElectronicsUnit u " + "WHERE u.powerElectronicsConnection = :conn", PowerElectronicsUnit.class) .setParameter("conn", connection) .getResultList(); // With pagination for large result sets: "SELECT e FROM Equipment e " + "WHERE e.equipmentContainer = :container", Equipment.class) .setParameter("container", substation) .setFirstResult(0) .setMaxResults(100) .getResultList(); References: Vlad Mihalcea, "The Best Way to Map a @OneToMany Relationship with JPA and Hibernate": https://vladmihalcea.com/the-best-way-to-map-a-onetomany-association-with-jpa-and-hibernate/ Vlad Mihalcea, "The Best Way to Use the @ManyToOne Annotation": https://vladmihalcea.com/manytoone-jpa-hibernate/ CIM Compound types are value objects — each compound row has exactly one owner (the specific parent column on the specific parent row that caused its creation) and is never shared. They are represented as separate @Entity classes with a surrogate UUID @Id auto-generated by the JPA provider on persist via @GeneratedValue(strategy=UUID). Compound references on parent entities use: @ManyToOne(fetch=FetchType.LAZY, cascade=CascadeType.REMOVE) @JoinColumn(name="compoundColumnName") CascadeType.REMOVE implements the value object ownership model — when a parent entity is deleted, its compound child entities are automatically deleted by the JPA provider, consistent with the ON DELETE CASCADE constraints in the companion SQL DDL script. Compound surrogate key UUID assignment is handled automatically by the JPA provider via @GeneratedValue — no application-level UUID generation code is required. See the companion sql-rdfs-ansi92 DDL script header for full details on the value object ownership model and the UUID generation directive. This file includes complete JPA 3.1 annotations on all generated entity classes. Unlike C#'s Entity Framework (EF) Core which requires explicit ModelConfiguration registration, JPA discovers all mappings — relationships, column definitions, inheritance strategy, and cascade behaviour — directly from the annotations on the generated classes. No additional configuration method needs to be called. To integrate these entities into a JPA application, define a persistence unit in META-INF/persistence.xml. The allClasses array at the bottom of this file provides the complete list of entity classes for this profile. For profiles with many classes, package scanning is strongly preferred over explicit <class> entries — maintaining 100+ class entries manually is impractical and any regeneration would require reconciling the list. Note: all generated entity classes are static inner classes of the outer class. When using explicit <class> entries in persistence.xml use the $ separator, e.g.: .$IdentifiedObject <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> <jar-file>cim-entities.jar</jar-file> <exclude-unlisted-classes>false</exclude-unlisted-classes> <properties> <property name="jakarta.persistence.jdbc.url" value="jdbc:..."/> <property name="hibernate.hbm2ddl.auto" value="validate"/> </properties> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <jar-file>cim-entities.jar</jar-file> <properties> <property name="jakarta.persistence.jdbc.url" value="jdbc:..."/> <property name="eclipselink.ddl-generation" value="none"/> </properties> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider> <jar-file>cim-entities.jar</jar-file> // Use the EntityManagerFactory directly via Persistence.createEntityManagerFactory. // This is the most portable approach and works with any JPA provider on the classpath. import jakarta.persistence.*; EntityManagerFactory emFactory = Persistence.createEntityManagerFactory(""); EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); // ... work with entities ... em.getTransaction().commit(); em.close(); emFactory.close() @SpringBootApplication @EntityScan("") @PersistenceContext(unitName = "") private EntityManager em; // application.yml: spring.jpa.hibernate.ddl-auto: validate // application.properties: quarkus.hibernate-orm.packages= quarkus.hibernate-orm.database.generation=none Use container-managed transactions and @PersistenceContext injection. Set transaction-type="JTA" with <jta-data-source> in persistence.xml. On servers with strict classloading (WebLogic, older WebSphere), use explicit <class> entries or <jar-file> rather than package scanning. @Stateless @PersistenceContext(unitName = "") private EntityManager em; The companion sql-rdfs-ansi92 DDL script is the authoritative schema and should always be used for production schema creation. JPA auto DDL generation (hbm2ddl.auto, ddl-generation, etc.) will not reproduce: - INTEGER DEFAULT 0 CHECK ("col" IN (0,1)) for boolean columns - Heuristic UNIQUE constraints on non-IdentifiedObject tables - Reverse-reference ON DELETE CASCADE for compound value objects Set ddl-generation/hbm2ddl.auto to "validate" or "none" in all environments where the SQL DDL script has been applied. public static final Class[] allClasses = new Class[] .class @Entity @Table(name="", indexes = {{ @Index(name="ix__", columnList=""), }}) @Table(name="") @Inheritance(strategy=InheritanceType.JOINED) @PrimaryKeyJoinColumn(name="mRID") mRID @Id @Column(name="mRID") @Override if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; IdentifiedObject that = (IdentifiedObject) o; return mRID != null && mRID.equals(that.mRID); @Override return getClass().hashCode(); @Table(name="", uniqueConstraints = {{ @UniqueConstraint(columnNames = {{"", }}) }}, indexes = {{ @Index(name="ix__", columnList=""), }}) @Table(name="", uniqueConstraints = {{ @UniqueConstraint(columnNames = {{"", }}) }}) @Table(name="", indexes = {{ @Index(name="ix__", columnList=""), }}) @Table(name="") @Inheritance(strategy=InheritanceType.JOINED) @PrimaryKeyJoinColumn(name="id") @Id @GeneratedValue(strategy=GenerationType.UUID) @Column(name="id") private UUID id; return id; this.id = id; @Override if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; that = () o; return id != null && id.equals(that.id); @Override return getClass().hashCode(); @Entity @Table(name="") name String @Id @Column(name="name") @Override if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; that = () o; return name != null && name.equals(that.name); @Override return getClass().hashCode(); @Entity @Table(name="", indexes = {{ @Index(name="ix__", columnList=""), }}) @Table(name="") @Id @GeneratedValue(strategy=GenerationType.UUID) @Column(name="id") private UUID id; return id; this.id = id; @Override if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; that = () o; return id != null && id.equals(that.id); @Override return getClass().hashCode(); fetch=FetchType.LAZY cascade=CascadeType.REMOVE optional=false @JoinColumn(name="") ───────────────────────────────────────────────────────────────────────────────────────── Suppressed @OneToMany: → [..*] The profile declares a [..*] association on this class to . A @OneToMany collection mapping has been intentionally suppressed: // NOT generated @OneToMany(mappedBy="", fetch=FetchType.LAZY) private List<> ; See "No @OneToMany Mappings — Intentional Design" in the file header for the full rationale. In summary: unbounded collections risk loading entire result sets into memory with no pagination, require bidirectional sync on every add/remove, and are not consistently present across profiles. Use an explicit JPQL query through the child side instead: Basic traversal: List<> results = em.createQuery( "SELECT x FROM x " + "WHERE x. = :parent", .class) .setParameter("parent", this) .getResultList(); Paginated traversal: List<> page = em.createQuery( "SELECT x FROM x " + "WHERE x. = :parent ORDER BY x.", .class) .setParameter("parent", this) .setFirstResult(offset) .setMaxResults(pageSize) .getResultList(); ───────────────────────────────────────────────────────────────────────────────────────── String @Column(name="", nullable=false) @Column(name="") @Column(name="", columnDefinition="INTEGER DEFAULT 0", nullable=false) @Column(name="", columnDefinition="INTEGER DEFAULT 0") @Column(name="", nullable=false) @Column(name="")