Delete the members of an aggregate which are referenced by their owner

[sven-n]

Fixes #933.

A member of an aggregate which is a collection holds its foreign key at the child, so the generated ON DELETE CASCADE removes it together with its owner. A member which is referenced by the owner (one-to-one) holds the foreign key at the owner instead, and a cascade only ever runs from the referenced row to the referencing one — so deleting the owner leaves the referenced row behind, unreachable. The cascade we generate for those 28 relationships today says "deleting the item storage deletes the character", which is the opposite of what's meant.

The most visible case is an item storage: every deleted character leaves its inventory behind, and with it every item lying in it. That happens in the normal game path (DeleteCharacterAction), not only in the bot purge, which worked around it by deleting the storages itself.

Since no foreign key can express the other direction, this uses a trigger — generated from the very annotation that states the intent, so it stays correct by construction: mark a member as [MemberOfAggregate] and its delete behaviour is right, whichever side holds the foreign key.

What's in here

• EfCoreModelGenerator generates AggregateDeleteTriggers.CreateScript next to the cascades it already emits: one delete_owned_row() function per schema, plus one after delete trigger per one-to-one member. The list is sorted, so the generated file is stable.
• A migration applies that script and deletes the item storages which were orphaned before the triggers existed (their items follow through the storage's own cascade). The script is copied into the migration on purpose — a migration has to keep applying what it applied when it was added, otherwise a fresh database would run it against columns which don't exist yet.
• A test fails when the generated script no longer matches what any migration applies, i.e. when someone adds a member of an aggregate and forgets the migration.
• BotGenerator no longer deletes the storages itself. It has to stop: EF orders the character delete before the storage delete, so the trigger has already removed the row when EF's own DELETE runs, and the save would fail with a DbUpdateConcurrencyException.

Triggers fire for rows deleted by a foreign key cascade as well, so delete from data."Account" alone now cleans up the characters and each of their inventories — a shallow or bulk delete is covered, which the application-side workaround could never do without loading the whole graph.

Two members are skipped

[MemberOfAggregate] is not a clean "owned exclusively" list today, and a trigger would make that dangerous rather than merely useless. Members whose target type is shared — it appears in a GameConfiguration collection or in the generator's StandaloneTypes — get no trigger and keep today's behaviour:

• Buff.MagicEffectDefinition — MagicEffectDefinition is in GameConfiguration.MagicEffects and also referenced by Skill.MagicEffectDef and ItemDefinition.ConsumeEffect.
• Skill.MasterDefinition — MasterSkillDefinition is in StandaloneTypes.

Two more are included but worth a second opinion from someone who knows the data better than the code shows: MiniGameChangeEvent.SpawnArea (a MonsterSpawnArea, which also appears in GameMapDefinition.MonsterSpawns) and QuestReward.ItemReward. Say the word and I'll exclude either.

Not in here

Flipping those 28 DeleteBehavior.Cascade to NoAction, which would also be right — the database currently carries a rule meaning the opposite of the aggregate semantics, harmless only because EF happens to order deletes dependent-first. It changes the model, so it needs a scaffolded migration with 28 foreign keys dropped and re-added plus a snapshot update; better as its own change.

Testing

The new unit test covers the generator/migration drift. What I could not verify here: this environment has no .NET SDK and no PostgreSQL, so the solution was not built and the migration was not executed against a database. The SQL was derived from EntityDataContextModelSnapshot.cs and every schema, table and column name in it was checked against that snapshot, and both script copies (the generated constant and the migration) were verified byte-identical. Still worth one run of the migration against a real database before merging.

Note this touches BotGenerator.DeleteAllBotsAsync, which #927 also changes — whichever lands first, I'm happy to rebase the other.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q9QAbEmp9rhnSWqZvkVaeN

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	8154d96
Status:	✅  Deploy successful!
Preview URL:	https://48613988.openmudocs.pages.dev
Branch Preview URL:	https://claude-pr927-cascade-delete.openmudocs.pages.dev

View logs