Directus项目中整数主键在字段验证中的类型匹配问题分析

问题背景

在Directus项目中，当开发者使用整数(INT)作为主键字段时，在创建或更新策略中进行字段验证时可能会遇到类型匹配问题。具体表现为：当验证规则中需要比较当前用户关联的整数ID字段时，系统会错误地认为验证失败，即使逻辑上两个值应该是相等的。

问题复现场景

假设我们有以下数据结构：

1. company表 - 使用自增INT作为主键
2. specialization表 - 同样使用自增INT主键
3. directus_users表 - 包含一个指向company表的外键字段

当系统自动创建多对多关联表company_specializations后，开发者可能会设置如下验证规则：

{
    "_and": [
        {
            "company_id": {
                "_eq": "$CURRENT_USER.company"
            }
        }
    ]
}

问题表现

在实际操作中，当用户尝试通过API创建关联记录时，即使提供的company_id与当前用户所属公司ID数值相同，系统仍会返回验证失败错误。错误信息显示系统期望值为"1"(字符串)，而实际值为1(整数)，表明存在类型不匹配问题。

技术分析

根本原因

1. 变量解析机制：Directus在解析$CURRENT_USER.company这类模板变量时，可能默认将其作为字符串处理
2. 类型严格比较：验证引擎在进行相等比较时没有自动进行类型转换
3. 整数主键特殊性：当主键使用自增INT时，数据库实际存储的是数值类型，而模板变量解析后可能产生字符串

影响范围

此问题主要影响以下场景：

• 使用整数(非UUID)作为主键的表
• 在权限验证规则中引用当前用户关联字段
• 进行精确匹配(_eq)验证时

解决方案建议

临时解决方案

开发者可以尝试以下方法临时解决问题：

1. 在验证规则中显式进行类型转换
2. 改用UUID作为主键类型
3. 使用自定义钩子进行验证

长期修复建议

从系统架构角度，建议：

1. 增强变量解析引擎的类型感知能力
2. 在验证比较中实现智能类型转换
3. 完善文档中关于类型处理的说明

最佳实践

在使用Directus进行开发时，特别是涉及权限验证的场景下，建议：

1. 优先考虑使用UUID作为主键
2. 在验证规则中明确处理类型问题
3. 对关键验证逻辑进行充分测试

总结

这个问题揭示了在权限系统中类型处理的重要性。作为开发者，在构建类似系统时需要特别注意数据类型的统一性，特别是在涉及用户上下文变量的场景中。Directus团队可以借此机会完善其类型处理机制，提升系统的健壮性。