Tolgee平台项目Slug设置问题分析与解决方案

问题背景

在Tolgee平台的最新版本中，开发团队发现了一个关于项目Slug设置的严重问题。当用户尝试为一个项目设置一个已被软删除(soft-deleted)项目占用的Slug时，系统会抛出约束违反(Constraint violation)异常，导致500服务器错误。这个问题不仅影响用户体验，还暴露了系统在Slug处理逻辑上的不足。

问题本质

Slug在Tolgee平台中作为项目的唯一标识符，其唯一性约束是必要的。然而，当前的实现存在两个关键缺陷：

1. 软删除项目的Slug冲突：系统在检查Slug唯一性时，没有考虑已被软删除的项目记录，导致当用户尝试使用已被软删除项目占用的Slug时，数据库约束被触发。

2. API创建项目时的Slug处理异常：通过API创建新项目时，即使明确指定了Slug参数，返回的项目模型中Slug字段却为null，用户必须通过额外的编辑操作来设置Slug。

技术分析

数据库层面

在典型的软删除实现中，记录不会被物理删除，而是通过一个标志位(如deleted字段)标记为已删除。Tolgee平台采用了这种模式，但在Slug唯一性检查时没有将软删除记录排除在外。

业务逻辑层

项目创建和更新的业务流程中，Slug的处理存在以下问题：

1. 创建项目时，Slug参数被接收但没有正确应用到返回模型中
2. 更新项目Slug时，唯一性检查逻辑不完整
3. 错误处理机制不够健壮，直接将数据库异常暴露给用户

解决方案

针对上述问题，建议从以下几个方面进行修复：

1. 完善Slug唯一性检查：

   • 修改查询逻辑，排除已软删除的项目记录
   • 在业务逻辑层而非数据库层实施这一约束
   • 提供有意义的错误提示，而非500错误

2. 修复API创建项目的Slug处理：

   • 确保创建项目时指定的Slug能正确保存并返回
   • 在创建时就进行完整的Slug验证

3. 增强错误处理：

   • 捕获并处理可能的约束违反异常
   • 返回用户友好的错误信息
   • 记录详细的错误日志供开发人员排查

实现建议

在具体实现上，可以考虑：

1. 修改Slug验证逻辑，添加对deleted=false的过滤条件
2. 在服务层添加专门的Slug验证方法
3. 为项目创建和更新操作添加事务支持
4. 完善API文档，明确Slug的处理规则

总结

Tolgee平台的Slug处理问题虽然看似简单，但涉及到了数据完整性、用户体验和系统稳定性等多个方面。通过这次修复，不仅能解决当前的500错误问题，还能提升整个平台在项目标识符处理上的健壮性。开发团队应当借此机会全面审视类似的数据唯一性约束，确保系统在各种边界条件下都能稳定运行。