Skip to content

Map existing PII-tree FKs into JPA entity relationships (CustomerAgreement/ServiceLocation tree) #169

@dfcoffin

Description

@dfcoffin

Gap (found by the #119 atom:link-vs-entity/DDL audit)

The Flyway DDL already has the foreign keys for the Customer/PII resource tree, but the JPA entity classes do not map them — so the PII XPath chain can't be navigated and the atom:link rel="related" links can't be emitted by the #119 resource surface.

Missing entity relationships (DDL FK present, JPA mapping absent)

Association (per NAESB 4.0 UML <<link>>) DDL FK Entity mapping
CustomerAccount ↔ CustomerAgreement
CustomerAgreement ↔ ServiceLocation
CustomerAgreement ↔ ServiceSupplier
CustomerAgreement ↔ ProgramDateIdMappings
ServiceLocation ↔ EndDevice
ServiceLocation ↔ Meter
ServiceLocation ↔ LocalTimeParameters (TimeConfiguration)

CustomerAgreementEntity, CustomerAccountEntity, ServiceLocationEntity, EndDeviceEntity, MeterEntity carry no @OneToMany/@ManyToOne/@OneToOne for these FK-linked siblings. (Already mapped/OK: Customer↔CustomerAccount, Customer↔Statement, Customer↔TimeConfiguration, *↔Statement, UsageSummary↔Statement.)

Why it matters

Prerequisite for the P-phase of the #119 resource surface: the entry assembler resolves related-resource ids via entity navigation, and the XPath endpoints (CustomerAgreement/{id}/ServiceLocation/{id}/EndDevice …) require the chain to be navigable. The DDL does not change — this is pure JPA relationship mapping of existing FKs (low risk).

Work

  • Add the missing @ManyToOne/@OneToMany (and @OneToOne for ServiceLocation↔LocalTimeParameters) mappings matching the existing FK columns + UML multiplicities.
  • Verify against customer.xsd (Verify Entity Field Types and Lengths Match ESPI 4.0 XSD Schemas #101) and the bidirectional <<link>> graph (NAESB 4.0 EA model).
  • Add/extend repository finder methods used by scope/related-link resolution (e.g., by-parent-id projections).

Related: #119 (resource surface, P-phase), #101/#123 (entity/DDL↔XSD), #168 (the analogous ProgramIdMappings energy gap).

Metadata

Metadata

Assignees

No one assigned

    Labels

    ESPI 4.0Touches the NAESB ESPI 4.0 implementationbugSomething isn't workingschema-complianceData elements comply with their appropriate ESPI schema definitions

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions