Summary
The migration to Thing is currently breaking NM_Aquifer legacy primary/foreign key relationships.
The core issue is failure to persist legacy NM_Aquifer identifiers (GUIDs) from Location and WellData as stable identities in Thing, which prevents downstream tables from maintaining correct foreign key relationships.
Background
Thing is acting as an identity unification layer for legacy NM_Aquifer entities (e.g., Location, Well, Site). However, current migrations treat Thing as a newly generated surrogate instead of a continuation of legacy identity.
As a result:
- Legacy PKs (e.g.,
LocationID, WellID) are not reliably persisted in Thing
- Downstream tables (e.g., WaterLevels, WeatherData) cannot reconstruct correct relationships
- Orphan prevention and FK enforcement fail because parent identity is ambiguous or lost
Issue 363 (adding thing_id FKs and cascade rules) is necessary but insufficient unless legacy identity is preserved first.
Core Requirements (Identity Preservation)
For NM_Aquifer entities that map to Thing:
-
Persist Legacy Primary Keys
- Store Location and WellData NM_Aquifer GUIDs in
Thing as a unique field, not primary key.
- One legacy GUID → exactly one
Thing
- No regeneration or remapping of identity
-
Explicit Legacy → Thing Mapping
- Location → Thing must persist
LocationID
- WellData → Thing must persist
WellID
- Mapping must be deterministic and cacheable
-
Foreign Key Continuity
- Cascading transfer scripts must:
- Resolve
thing_id via legacy GUID lookup
- Don't infer relationships indirectly (e.g., via
PointID non-unique columns)
- All child tables must reference the same
Thing created from the legacy parent
Downstream Enforcement (After Identity Is Correct)
Once identity continuity is guaranteed, enforce relational integrity:
1. Child Models
thing_id FK with NOT NULL
ondelete="CASCADE"
- Python-level orphan prevention via
@validates
2. Thing Reverse Relationships
cascade="all, delete-orphan"
passive_deletes=True
Acceptance Criteria
- Location and WellData NM_Aquifer legacy GUIDs are persisted in
Thing
- No duplicate
Thing rows for a single legacy entity
- Cascading transfers resolve parents via legacy GUIDs
- All Thing children have enforced
thing_id FKs
- Orphan creation is impossible at DB and ORM levels
- Tests assert identity continuity across migrations
References
- Issue 363
JIRA Ticket
Summary
The migration to
Thingis currently breaking NM_Aquifer legacy primary/foreign key relationships.The core issue is failure to persist legacy NM_Aquifer identifiers (GUIDs) from Location and WellData as stable identities in
Thing, which prevents downstream tables from maintaining correct foreign key relationships.Background
Thingis acting as an identity unification layer for legacy NM_Aquifer entities (e.g., Location, Well, Site). However, current migrations treatThingas a newly generated surrogate instead of a continuation of legacy identity.As a result:
LocationID,WellID) are not reliably persisted inThingIssue 363 (adding
thing_idFKs and cascade rules) is necessary but insufficient unless legacy identity is preserved first.Core Requirements (Identity Preservation)
For NM_Aquifer entities that map to
Thing:Persist Legacy Primary Keys
Thingas a unique field, not primary key.ThingExplicit Legacy → Thing Mapping
LocationIDWellIDForeign Key Continuity
thing_idvia legacy GUID lookupPointIDnon-unique columns)Thingcreated from the legacy parentDownstream Enforcement (After Identity Is Correct)
Once identity continuity is guaranteed, enforce relational integrity:
1. Child Models
thing_idFK withNOT NULLondelete="CASCADE"@validates2. Thing Reverse Relationships
cascade="all, delete-orphan"passive_deletes=TrueAcceptance Criteria
ThingThingrows for a single legacy entitything_idFKsReferences
- Issue 363