From 6d267f2269cfe55de41bb05f9956191a95517e1c Mon Sep 17 00:00:00 2001
From: Marcel <marcel@familienarchiv>
Date: Sat, 6 Jun 2026 11:48:10 +0200
Subject: [PATCH] test(person): describe DB-cascade mechanism in delete
 service-path test (#684)

The deletePerson service-path guard (AC-4) is unchanged behaviourally, but its
comments described the removed reassignSenderToNull/deleteReceiverReferences
chain. Update them to the V71 ON DELETE cascade mechanism.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../person/PersonServiceIntegrationTest.java     | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/backend/src/test/java/org/raddatz/familienarchiv/person/PersonServiceIntegrationTest.java b/backend/src/test/java/org/raddatz/familienarchiv/person/PersonServiceIntegrationTest.java
index dfb1fa57..d26883cd 100644
--- a/backend/src/test/java/org/raddatz/familienarchiv/person/PersonServiceIntegrationTest.java
+++ b/backend/src/test/java/org/raddatz/familienarchiv/person/PersonServiceIntegrationTest.java
@@ -180,9 +180,9 @@ class PersonServiceIntegrationTest {
     @Test
     void deletePerson_detachesSentAndReceivedReferences_beforeDelete_noOrphan() {
         // A person referenced as BOTH a document sender and a document receiver must delete
-        // cleanly: deletePerson nulls the sender_id FK and removes the receiver join row first
-        // (reassignSenderToNull → deleteReceiverReferences → deleteById), so no FK orphan and
-        // the documents themselves survive.
+        // cleanly via the service path: deletePerson just calls deleteById, and V71's ON DELETE
+        // constraints null the sender_id FK and drop the receiver join row, so there is no FK
+        // orphan and the documents themselves survive.
         Person target = personRepository.save(Person.builder()
                 .firstName("Weg").lastName("Person").provisional(true).build());
         Person bystander = personRepository.save(Person.builder()
@@ -196,16 +196,16 @@ class PersonServiceIntegrationTest {
                 .status(DocumentStatus.UPLOADED).sender(bystander)
                 .receivers(new java.util.HashSet<>(Set.of(target))).build());
 
-        // Persist the fixture and detach everything so the native @Modifying deletes operate on
-        // the database directly without the persistence context holding stale references that
-        // would re-flush a now-deleted person as a transient association.
+        // Persist the fixture and detach everything so the delete operates on the database
+        // directly without the persistence context holding stale references.
         entityManager.flush();
         entityManager.clear();
 
         personService.deletePerson(target.getId());
 
-        // Native @Modifying queries bypass the persistence context — clear it so the asserting
-        // reads observe the post-delete database state, not stale managed entities.
+        // The ON DELETE cascade fires beneath Hibernate — flush the delete and clear the L1
+        // cache so the asserting reads observe the post-delete database state, not stale
+        // managed entities (the EAGER @ElementCollection on receivers makes this load-bearing).
         entityManager.flush();
         entityManager.clear();