ZenStack中日期字段与Futures结合使用的注意事项

前言

在使用ZenStack进行数据建模时，开发者经常会遇到需要对未来状态进行验证的场景。特别是在处理包含日期/时间字段的模型时，如何正确使用Futures功能进行验证是一个需要特别注意的技术点。本文将深入分析一个典型的使用案例，帮助开发者避免常见陷阱。

问题背景

在数据模型中，我们经常需要设置一些业务规则来限制对日期字段的修改。例如，在软删除场景中，我们可能希望：

1. 禁止将删除时间设置为未来时间
2. 确保已删除记录不能被再次修改

这些需求看似简单，但在ZenStack的实现中却存在一些需要特别注意的细节。

典型错误示例

考虑以下模型定义：

model Test {
  id         String    @id @default(dbgenerated("uuid_generate_v4()")) @db.Uuid
  deleted_at DateTime? @db.Timestamp(6)

  @@allow('all', true)
  @@deny("update", 
    deleted_at != null ||
    future().deleted_at > now()
  )
}

开发者期望实现：

1. 已删除记录（deleted_at不为null）禁止修改
2. 不能将deleted_at设置为未来时间

然而，这种实现方式在实际运行中会出现意外行为。

问题根源分析

问题的核心在于PostgreSQL处理NULL值的方式。当ZenStack执行"post-update"规则检查时：

1. 对于deleted_at != null部分，在检查时它始终为false
2. 因此系统会评估future().deleted_at > now()
3. ZenStack将其转换为Prisma查询：{ NOT: { deleted_at: { gt: new Date() } } }
4. 在PostgreSQL中，任何与NULL的比较都会返回NULL
5. 最终导致规则检查失败

正确实现方式

正确的实现应该显式处理NULL值的情况：

model Test {
  id         String    @id @default(dbgenerated("uuid_generate_v4()")) @db.Uuid
  deleted_at DateTime? @db.Timestamp(6)

  @@allow('all', true)
  @@deny("update", 
    future().deleted_at != null &&
    future().deleted_at > now()
  )
}

这种实现方式：

1. 首先检查deleted_at是否不为NULL
2. 只有当不为NULL时，才检查它是否大于当前时间
3. 完全避免了NULL值比较带来的问题

最佳实践建议

1. 显式处理NULL值：在使用Futures时，总是显式检查字段是否为NULL
2. 优先使用正向规则：尽可能使用@@allow而非@@deny，逻辑通常更清晰
3. 充分测试：对日期字段的规则进行全面的单元测试，包括边界情况
4. 理解数据库行为：了解底层数据库对NULL值的处理方式，避免意外行为

总结

在ZenStack中使用Futures功能处理日期字段时，开发者需要特别注意NULL值的处理。通过显式检查字段是否为NULL，可以避免许多潜在问题。理解这些细节将帮助开发者构建更加健壮的数据访问控制层。