Ecto中`:writable`选项在`:insert`模式下的行为解析

背景介绍

在使用Ecto ORM框架进行数据库操作时，我们经常需要控制某些字段的可写性。Ecto提供了:writable选项来定义字段的写入权限，其中:writable: :insert表示该字段只能在插入操作时被写入，后续更新操作中应该被忽略。

问题现象

开发者发现当使用:writable: :insert选项定义字段后，在更新操作中该字段仍然可以被修改。具体表现为：

1. 定义了一个带有:writable: :insert选项的字段
2. 在更新操作中尝试修改该字段
3. 更新操作成功返回，且返回的结构体中显示字段已被修改

技术分析

实际上，这是一个理解上的误区。Ecto的行为是：

1. 数据库层面确实忽略了该字段的更新（通过检查数据库确认）
2. 但返回的结构体仍然包含用户尝试修改的值
3. 这是因为Ecto默认不会从数据库重新读取所有字段

解决方案

有三种方式可以解决这个问题：

方案一：使用不同的changeset

为插入和更新操作分别定义不同的changeset函数，在更新changeset中不包含只允许插入的字段。

def insert_changeset(account, attrs) do
  account
  |> cast(attrs, [:firebase_uid, :deactivated_at])
  |> validate_required([:firebase_uid])
end

def update_changeset(account, attrs) do
  account
  |> cast(attrs, [:deactivated_at])
end

方案二：使用:returning选项

在Repo.update调用中显式设置:returning: true，强制从数据库重新读取所有字段：

Repo.update(changeset, returning: true)

方案三：等待Ecto修复

Ecto团队已经确认这是一个需要改进的行为，未来版本可能会自动过滤掉不可写字段的更新。

最佳实践建议

目前推荐使用方案一（不同的changeset）作为临时解决方案，因为：

1. 它更明确地表达了业务意图
2. 不依赖数据库的特定行为
3. 性能更好（不需要额外的数据库读取）

深入理解Ecto的更新机制

理解这个问题需要了解Ecto的几个关键设计：

1. Changeset原则：Ecto通过changeset来跟踪和验证变更，但changeset本身不强制数据库约束
2. 部分更新：Ecto默认只发送实际变更的字段到数据库
3. 返回策略：默认情况下，Ecto不会重新读取所有字段，而是合并数据库返回的字段和用户提供的值

总结

Ecto的:writable选项在:insert模式下目前存在行为与预期不符的情况，但通过理解Ecto的工作机制，我们可以采用适当的解决方案。这个问题也提醒我们，在使用ORM框架时，不仅要了解表面API，还需要深入理解其背后的数据流和状态管理机制。

对于需要严格控制字段写入权限的场景，显式地使用不同的changeset是目前最可靠的方式。随着Ecto框架的演进，这个问题有望得到更优雅的解决。