Dinky项目中的目录命名冲突问题分析与解决方案

问题背景

在Dinky数据开发平台1.2.1版本中，用户在使用"数据开发-项目"功能时遇到了一个影响使用体验的问题。具体表现为：当用户尝试在不同父目录下创建同名子目录时，系统会错误地提示"目录或作业已存在"，而实际上这些目录位于不同的层级结构中，理论上应该允许创建。

问题现象

用户报告的具体场景如下：

1. 在项目A目录下创建名为"公共环境"的子目录成功
2. 当尝试在项目B目录下创建同样名为"公共环境"的子目录时
3. 系统错误地返回"操作未成功"提示，并显示"A task and a directory cannot have the same name under the same parent directory"

技术原因分析

经过深入分析，我们发现问题的根源在于以下几个方面：

1. 数据库设计层面：Dinky的目录表(dinky_catalogue)确实建立了正确的唯一索引(name, parent_id, tenant_id)，这个索引设计理论上应该允许不同父目录下的同名子目录存在。

2. 业务逻辑实现问题：在CatalogueServiceImpl.checkNameIsExistByParentId方法中，查询条件没有正确使用这三个字段的组合条件。具体来说，代码中错误地将"不等于"(ne)条件用在了parent_id字段上，而实际上应该使用"等于"(eq)条件。

3. 多租户处理：虽然tenant_id字段是索引的一部分，但它是通过MyBatisPlus的TenantLineInterceptor自动处理的，在业务代码中没有显式使用。

解决方案

针对这个问题，我们提出了以下解决方案：

1. 修正查询条件：将CatalogueServiceImpl.checkNameIsExistByParentId方法中的parent_id字段查询条件从"ne"改为"eq"，确保查询能够正确利用数据库索引。

2. 测试验证：修改后需要进行全面的测试，包括：

   • 同父目录下不允许同名目录/作业
   • 不同父目录下允许同名目录/作业
   • 跨租户的同名目录/作业处理

3. 代码审查：检查项目中其他类似场景的命名冲突检查逻辑，确保不会出现相同问题。

技术实现细节

在Dinky的实现中，目录和作业的命名冲突检查是通过以下方式工作的：

1. 数据库约束：数据库表建立了(name, parent_id, tenant_id)的复合唯一索引，确保同一租户下同一父目录中不会出现同名项。

2. 业务层检查：在创建或重命名操作前，会先调用checkNameIsExistByParentId方法进行检查。

3. 多租户隔离：通过MyBatisPlus的租户拦截器自动在SQL中添加tenant_id条件，实现租户间的数据隔离。

最佳实践建议

基于这个问题的解决，我们建议Dinky用户和开发者注意以下几点：

1. 版本升级：建议用户升级到包含此修复的版本，以获得更好的使用体验。

2. 命名规范：虽然系统现在支持不同目录下的同名项，但仍建议制定清晰的命名规范以避免混淆。

3. 自定义开发：如果需要进行二次开发，应当注意类似场景下的命名冲突检查逻辑实现。

总结

这个问题的解决不仅修复了一个影响用户体验的bug，也提醒我们在开发类似功能时需要注意：数据库约束和业务逻辑检查必须保持一致，特别是在处理层级结构和命名冲突的场景下。Dinky团队快速响应并修复了这个问题，体现了对产品质量和用户体验的重视。