Gin-Vue-Admin项目中getXXXDataSource接口的软删除记录问题分析

在Gin-Vue-Admin项目开发过程中，开发者可能会遇到一个关于数据源获取接口的典型问题：使用代码生成的getXXXDataSource接口会意外获取到已被软删除的记录。这个问题看似简单，但背后涉及GORM框架的使用细节和软删除机制的工作原理。

问题现象

当开发者使用自动生成的getXXXDataSource接口获取数据源时，发现返回结果中包含了本应被软删除的记录。例如，在获取应用列表时，即使某些应用记录已被标记为删除，它们仍然出现在下拉选项的数据源中。

原因分析

通过查看源码可以发现，问题的根源在于查询构建方式的选择。原代码使用了Table()方法直接指定表名进行查询：

global.MustGetGlobalDBByDBName("user_manager").Table("apps").Select("name as label,id as value").Scan(&appId)

这种写法绕过了GORM的模型关联机制，导致GORM无法自动应用软删除相关的查询条件。在GORM中，软删除功能是通过模型定义中的DeletedAt字段实现的，当使用Model()方法关联模型时，GORM会自动添加WHERE deleted_at IS NULL条件。

解决方案

正确的做法是使用Model()方法关联模型结构体，而非直接使用表名：

global.MustGetGlobalDBByDBName("user_manager").Model(&userManager.Apps{}).Select("name as label,id as value").Scan(&appId)

这种写法确保了GORM能够识别模型中的软删除标记，并自动过滤掉已被软删除的记录。

深入理解

1. GORM的软删除机制：GORM通过在模型结构体中嵌入gorm.DeletedAt字段来实现软删除功能。当使用Delete()方法时，GORM不会真正删除记录，而是更新deleted_at字段为当前时间。

2. 查询构建差异：

   • 使用Table()方法：直接操作数据库表，绕过GORM的模型关联和钩子机制
   • 使用Model()方法：关联模型结构体，启用GORM的全部功能，包括软删除过滤

3. 性能考量：虽然两种写法在性能上差异不大，但Model()方法提供了更好的类型安全和功能完整性。

最佳实践建议

1. 在Gin-Vue-Admin项目中，应始终优先使用Model()方法而非Table()方法进行查询
2. 对于需要包含软删除记录的特殊场景，可以使用Unscoped()方法显式取消软删除过滤
3. 在代码生成模板中，应考虑修改默认生成的查询逻辑以避免此问题

总结

这个案例展示了框架使用细节对系统行为的重要影响。作为开发者，理解ORM框架的工作原理和最佳实践至关重要。在Gin-Vue-Admin项目中正确使用GORM的查询构建方法，不仅能避免软删除记录泄露的问题，还能确保数据访问的一致性和安全性。