DSpace中EPerson无法删除的原因及非cascade删除方案咨询

一、不使用CASCADE删除EPerson的方法 #

要保留用户上传的资源，核心是先解除EPerson与关联表的外键绑定，而非直接级联删除关联数据，具体步骤如下：

• 第一步：清理关联外键引用
  根据你的错误提示，item表的submitter_id字段关联了要删除的EPerson UUID。你可以选择两种方式处理：
  1. 若外键允许为NULL，直接将关联记录的submitter_id设为NULL：

     UPDATE item SET submitter_id = NULL WHERE submitter_id = 'c8733cae-ec0d-469d-bf64-81e6b7f3e589';
     

  2. 若外键不允许为NULL，先创建一个预设的“匿名用户”或“系统用户”EPerson，再将关联记录的submitter_id替换为这个新用户的UUID：

     -- 假设新匿名用户UUID为xxxx-xxxx-xxxx-xxxx
     UPDATE item SET submitter_id = 'xxxx-xxxx-xxxx-xxxx' WHERE submitter_id = 'c8733cae-ec0d-469d-bf64-81e6b7f3e589';
     

• 第二步：删除目标EPerson
  完成关联清理后，即可安全删除EPerson：

  DELETE FROM eperson WHERE uuid = 'c8733cae-ec0d-469d-bf64-81e6b7f3e589';
  

  注意：如果代码库中有对应的业务服务类，建议优先调用服务层的方法处理关联更新，避免直接操作数据库破坏业务逻辑。

二、EPersonDeletionException的设计原因 #

这个异常类的核心作用是在代码层面提前拦截非法删除操作，保障数据完整性与业务逻辑一致性：

• 从业务角度看，EPerson作为资源的提交者/创建者，其关联记录（如item表的submitter_id）属于关键元数据，直接删除EPerson会导致这些元数据失去有效关联，无法追溯资源的归属信息。
• 从技术角度看，它是数据库外键约束的上层封装：数据库本身会通过外键阻止删除有引用的EPerson（也就是你遇到的错误），而这个异常类会在执行删除操作前，提前检查EPerson是否存在于item等特定关联表中，提前抛出明确的业务异常，避免数据库层面的模糊报错，让开发者更清晰地知道需要先处理关联关系。

内容的提问来源于stack exchange，提问作者Sungket