示例
Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database.
sha256:1e2a19ac37ba6adfa3f491b086bfc7d9a193727d9a750b88d8379b12a21249fb
PUBLISHED
L3_CONTRACT_PASS
MIT-0
执行证据
分开显示声明环境和签名验证运行,明确样本的证明范围。
证据依据签名契约通过
验证回执1
验证级别L3_CONTRACT_PASS
声明的环境
- 执行上下文
- elixir
- 操作系统
- linux
- 架构
- x64
- 运行时
- elixir
- 语言
- elixir
- 包管理器
- mix
验证运行环境
- 执行上下文
- elixir 1
- 操作系统
- linux alpine · musl
- 架构
- x64
- 运行时
- elixir 1
- 语言
- elixir
- 包管理器
- mix
- 执行方式
- container · docker
CONTAINER_RUN · compile:PASS · contract:PASS · load:PASS · resolve:PASS · hex@1 · 2026-08-17
案例
- 目标
- Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database. HOW
- 包
-
ecto 3.14.1
- 环境
- elixir
- 创建时间
- 2026-08-17T04:43:50Z
常见的想当然
A competent Ecto user expects `optimistic_lock/2` to protect updates using the row's current stored `:lock_version`, and that unsafely cast `:lock_version` params cannot influence the value used in the conflict check.
这是本样本作者记下的、开发者或模型在此处通常会有的预期。下面的契约才是真正运行过的东西。
契约
- When `:lock_version` is not cast, `optimistic_lock/2` keeps the filter at the struct value, but once `:lock_version` is allowed in `cast/3`, `optimistic_lock/2` switches the filter to that user-supplied value, so checks can run against a client-controlled token.
- After `optimistic_lock/2`, a casted `:lock_version` value is still bumped in place, so `get_change/3` and `apply_changes/1` reflect an incremented counter even though no Repo is involved.
文件
- NOTES.md
- csx.json
- mix.exs
- mix.lock
- test/contract.exs
下载源代码构件 (tar.gz)
原始种子者
csx-seed
验证回执
- elixir 1 · linux alpine/x64 · docker · CONTAINER_RUN · compile:PASS · contract:PASS · load:PASS · resolve:PASS · hex@1 · 2026-08-17 · ed25519:d91480838ac982c9