While reconciling #56 (System_ChangeLog), the developer raised a question worth deciding on its own: should System_-prefixed provenance tables (System_AuditEntries, System_ImportConflicts, and the new System_ChangeLog) actually purge rows that reference an entity a full database Reset just wiped and reseeded with a new ID, instead of blanket-surviving Reset as all three do today?
Current behavior
Per CLAUDE.md's Reset design and Sql.Schema.GetUserTables, any System_-prefixed table is excluded from the tables a Reset drops — this is deliberate and tested (ResetAsync_PreservesExistingImportConflictRows, ResetAsync_AfterInitialise_PreservesExistingAuditEntries, and the equivalent for System_ChangeLog once #56 ships).
The rationale documented so far: these are provenance/history tables, and the event they record (a conflict was resolved, an operation happened, a row was created) is a fact about what occurred, independent of whether the referenced row still exists afterward.
The question
If a Reset wipes Quotes/Sources/Characters/People and reseeds them with brand-new UUIDs, every pre-Reset row in these three tables ends up pointing at an EntityId/RecordId that no longer exists in the domain tables — a dangling reference. Is that:
- (a) Acceptable and intended — these are historical/audit records, not foreign keys; a dangling reference to a since-replaced row is still a true historical fact and should be kept, or
- (b) A design flaw — a change-log/audit/conflict row whose subject no longer exists (and never will again, since re-seeding generates fresh IDs) carries no continuing value and should be purged as part of Reset, the same way the domain data it describes is purged
Scope
This spans three tables/milestones:
Deciding this would mean either documenting (a) as the deliberate, permanent design (closing this issue with no code change), or implementing (b) — which would need a mechanism to detect "does this EntityId/RecordId still exist in a live domain table" before or during Reset, for all three tables, without Quotinator.Data gaining a dependency on Quotinator's specific domain schema (it currently deliberately does not know what a "Quote" is).
Not scoped to Data Import & Sources specifically — it's a cross-cutting architecture question, hence filed against the maintenance milestone.
While reconciling #56 (
System_ChangeLog), the developer raised a question worth deciding on its own: shouldSystem_-prefixed provenance tables (System_AuditEntries,System_ImportConflicts, and the newSystem_ChangeLog) actually purge rows that reference an entity a full database Reset just wiped and reseeded with a new ID, instead of blanket-surviving Reset as all three do today?Current behavior
Per CLAUDE.md's Reset design and
Sql.Schema.GetUserTables, anySystem_-prefixed table is excluded from the tables a Reset drops — this is deliberate and tested (ResetAsync_PreservesExistingImportConflictRows,ResetAsync_AfterInitialise_PreservesExistingAuditEntries, and the equivalent forSystem_ChangeLogonce #56 ships).The rationale documented so far: these are provenance/history tables, and the event they record (a conflict was resolved, an operation happened, a row was created) is a fact about what occurred, independent of whether the referenced row still exists afterward.
The question
If a Reset wipes
Quotes/Sources/Characters/Peopleand reseeds them with brand-new UUIDs, every pre-Reset row in these three tables ends up pointing at anEntityId/RecordIdthat no longer exists in the domain tables — a dangling reference. Is that:Scope
This spans three tables/milestones:
System_AuditEntries— general infra, predates any specific milestoneSystem_ImportConflicts— Import conflict resolution: per-import policy with configurable defaults #64, Data Import & Sources milestoneSystem_ChangeLog— Audit log: provenance and change history across all entity types #56, Data Import & Sources milestoneDeciding this would mean either documenting (a) as the deliberate, permanent design (closing this issue with no code change), or implementing (b) — which would need a mechanism to detect "does this EntityId/RecordId still exist in a live domain table" before or during Reset, for all three tables, without
Quotinator.Datagaining a dependency on Quotinator's specific domain schema (it currently deliberately does not know what a "Quote" is).Not scoped to Data Import & Sources specifically — it's a cross-cutting architecture question, hence filed against the maintenance milestone.