샘플
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