Ecto中put_assoc与unique_constraint的深度嵌套验证问题解析

问题背景

在Elixir生态中，Ecto作为数据库包装器和查询语言，提供了强大的数据验证和关联管理功能。开发者在处理复杂数据模型时，经常会遇到多层嵌套结构的数据验证问题。本文探讨一个典型场景：当使用put_assoc操作深度嵌套的关联结构时，unique_constraint验证可能被意外忽略的情况。

核心问题分析

在Ecto的数据处理流程中，开发者通常会采用两步验证策略：

1. 首先通过嵌入式模式(embedded schema)验证输入数据的格式和基本规则
2. 然后将验证后的数据映射到实际的数据库模式(db schema)

问题出现在第二步的映射过程中。当开发者直接使用put_assoc将已验证的嵌入式模式结构体直接关联到主模式时，Ecto会跳过对这些关联数据的进一步验证，包括unique_constraint检查。

技术细节解析

put_assoc的工作机制

put_assoc函数有三种处理关联数据的方式：

1. 接收map或keyword list：会进行常规的验证和转换
2. 接收changeset：作为规范数据直接使用
3. 接收结构体(struct)：作为规范数据直接使用，替换现有关联

关键在于第三种情况——当直接传入结构体时，Ecto会完全信任这些数据，不会进行任何验证，包括在changeset中定义的unique_constraint。

unique_constraint的验证时机

unique_constraint验证有其特殊性：

1. 它不是在changeset构建阶段执行的
2. 只有在实际执行数据库操作时才会触发
3. 验证信息存储在changeset结构中

当通过put_assoc直接传入结构体时，相关的约束信息不会包含在最终的changeset中，导致数据库操作时约束违规会直接抛出异常，而不是返回带有错误信息的changeset。

解决方案

推荐方法：通过中间map转换

最可靠的解决方案是将嵌入式模式先转换为普通map，再通过cast_assoc进行关联处理：

attrs = %{
  "account" => %{
    "firebase_uid" => fuid,
    "role" => :user,
    "account_info" => %{
      "phone_number" => create.phone_number,
      "first_name" => create.first_name,
      "last_name" => create.last_name
    }
  }
}

%User{}
|> cast(attrs, [])
|> cast_assoc(:account, required: true)

这种方法确保了所有验证规则都会被正常触发。

替代方案：显式构建changeset

如果确实需要保留结构体形式，可以显式为每个嵌套关联构建changeset：

account_info_changeset = AccountInfo.changeset(
  %AccountInfo{},
  %{
    phone_number: create.phone_number,
    first_name: create.first_name,
    last_name: create.last_name
  }
)

account_changeset = Account.changeset(
  %Account{firebase_uid: fuid, role: :user},
  %{account_info: account_info_changeset}
)

%User{}
|> change()
|> put_assoc(:account, account_changeset)

最佳实践建议

1. 对于外部输入数据，始终通过changeset进行验证
2. 在多层嵌套结构中，优先使用cast_assoc而非put_assoc
3. 当需要在关联中应用约束验证时，确保相关changeset被正确构建
4. 对于内部已验证数据，可以适当使用put_assoc提高性能，但需明确知晓验证会被跳过

总结

Ecto的这种设计实际上是一种合理的权衡——当开发者明确传入结构体时，Ecto认为这些数据已经过验证，可以信任。理解这一机制有助于开发者在数据验证的严格性和性能之间做出合理选择。在需要确保所有验证规则都被执行的场景下，通过中间map转换是最可靠的方法。