feat: Issue #97 - Standardize relatedLinks Infrastructure with Composition Pattern #99
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Extended Phase A0 (PREREQUISITE) to include bidirectional Atom links for EndDevice and Meter entities in addition to the original 4 entities: Previous (4 entities): - CustomerAgreement - ProgramDateIdMappings - ServiceLocation - ServiceSupplier Added (2 additional entities): - EndDevice - Meter (inherits from EndDevice) Investigation confirmed: - All 6 related_links database tables exist in V3 migration - All 6 entities lack @ElementCollection mappings for relatedLinks - Bidirectional relationships required: - ServiceLocation ↔ EndDevice - ServiceLocation ↔ Meter - CustomerAgreement ↔ ProgramDateIdMappings - CustomerAgreement ↔ ServiceLocation - CustomerAgreement ↔ ServiceSupplier Per NAESB ESPI 4.0 standard, these relationships are implemented via Atom <link rel="related"> elements, not via customer.xsd definitions. Related to #28 (Phase 17: ProgramDateIdMappings)
…ition Pattern Implements Issue #97 to standardize relatedLinks infrastructure across all ESPI entities using @AssociationOverride and composition pattern with Lombok @DeleGate. Key Changes: - Converted Asset from @MappedSuperclass to @embeddable for composition - Created EndDeviceFields @embeddable for 4 EndDevice-specific fields - Refactored EndDeviceEntity and MeterEntity to use composition instead of inheritance - Both entities now embed Asset + EndDeviceFields with @DeleGate for transparent access - Added @AssociationOverride to 13 entities (4 usage domain + 9 customer domain) Entity Changes: - Usage Domain: ApplicationInformationEntity, AuthorizationEntity, ElectricPowerQualitySummaryEntity, ReadingTypeEntity - Customer Domain: CustomerEntity, CustomerAccountEntity, CustomerAgreementEntity, EndDeviceEntity, MeterEntity, ProgramDateIdMappingsEntity, ServiceLocationEntity, ServiceSupplierEntity, StatementEntity Mapper Updates: - EndDeviceMapper: Updated to map from nested embedded objects (asset.*, endDeviceFields.*) - MeterMapper: Updated to map from nested embedded objects (asset.*, endDeviceFields.*) - Required because MapStruct runs before Lombok @DeleGate generates delegation methods Database Migrations: - V1__Create_Base_Tables.sql: Added relatedLinks tables for usage domain entities - V3__Create_additiional_Base_Tables.sql: Added relatedLinks tables for customer domain, expanded meters table with all IdentifiedObject, Asset, and EndDeviceFields columns Technical Details: - Resolved Hibernate inheritance conflict where MeterEntity couldn't override relatedLinks - Used composition (HAS-A) instead of inheritance (IS-A) per NAESB ESPI 4.0 customer.xsd - Lombok @DeleGate provides transparent access to embedded fields for service layer - Each entity now has separate relatedLinks join table via @AssociationOverride Test Results: - All 760 unit tests passing - H2 in-memory database integration: 3 tests passing - MySQL TestContainers integration: 2 tests passing - PostgreSQL TestContainers integration: 59 tests passing - Total: 824+ tests passing across all database platforms Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added JPA mapping guideline for entity toString() method sequencing to ensure consistency with database schema definitions. Guideline enforces that toString() methods must follow exact database field sequence from Flyway migration scripts: - Standard sequence: id, description, created, updated, published, upLink, selfLink, [type-specific fields in database column order], relatedLinks - Ensures toString() output matches CREATE TABLE statement column order - Improves debugging and log readability by maintaining schema alignment This guideline supports Issue #97 relatedLinks standardization work where consistent field ordering across entities is critical. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Key Technical Changes
Architecture Refactoring:
Assetfrom @MappedSuperclass to @embeddable for compositionEndDeviceFields@embeddable for 4 EndDevice-specific fields (isVirtual, isPan, installCode, amrSystem)EndDeviceEntityandMeterEntitynow extendIdentifiedObjectdirectly and embed Asset + EndDeviceFieldsEntity Updates (13 entities):
Mapper Updates:
Database Migrations:
Test Plan
Total: 824+ tests passing across all database platforms
Files Changed
19 files changed (542 insertions, 335 deletions):
Related Issues
Closes #97
🤖 Generated with Claude Code