Remove legacy Long id field from IdentifiedObject-based DTOs

[dfcoffin]

Problem

DTOs for entities that inherit from IdentifiedObject currently have two ID fields:

1. Long id - Legacy field from when entities used Long primary keys
2. String uuid - Current field holding the UUID string representation

Since all entities now use UUID primary keys (not Long), the Long id field is:

• Marked @XmlTransient (not serialized to XML)
• Marked @Mapping(target = "id", ignore = true) in MapStruct mappers
• Not actively used in any mapping logic
• Only kept for backward compatibility

Affected DTOs

All DTOs in the following packages that correspond to IdentifiedObject-based entities:

Usage Domain (dto/usage/):

• ApplicationInformationDto
• AuthorizationDto
• ElectricPowerQualitySummaryDto
• IntervalBlockDto
• MeterReadingDto
• ReadingTypeDto
• TimeConfigurationDto
• UsagePointDto
• UsageSummaryDto
• (and any others that have both Long id and String uuid fields)

Customer Domain (dto/customer/):

• CustomerDto
• CustomerAccountDto
• CustomerAgreementDto
• EndDeviceDto
• MeterDto
• ProgramDateIdMappingsDto
• ServiceLocationDto
• StatementDto
• (and any others that have both Long id and String uuid fields)

Proposed Solution

1. Remove Long id field from all affected DTOs
2. Keep only String uuid field (marked @XmlTransient)
3. Update constructors to remove the Long id parameter
4. Update mapper @Mapping annotations to remove ignore = true for id field
5. Verify all tests still pass

Benefits

• Simplifies DTO structure
• Removes confusion about which ID field to use
• Eliminates legacy backward compatibility code
• Makes codebase cleaner and easier to maintain

Related Work

This issue was identified during Phase 5 (IntervalBlock) of ESPI 4.0 Schema Compliance work (Issue #28).

Acceptance Criteria

• All Long id fields removed from IdentifiedObject-based DTOs
• All constructor signatures updated
• All MapStruct mappers updated
• All unit tests pass
• All integration tests pass
• Documentation updated if necessary

[dfcoffin]

No longer an issue, resolved by PR #86