Add a way to run callbacks after a transaction commits
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start with opsqueue/src/db/mod.rs, where Connection::transaction() is defined, and read the linked discussion in issues #182 and #193 for context. The issue proposes storing callbacks on transactions, running them after a successful outermost commit, and propagating them from nested transactions. Done means callbacks run only after commit and nested transactions pass them upward; the issue leaves key design details open.
索引モデルが issue の本文から書いたものです。
説明
Related: https://github.com/channable/opsqueue/issues/182#issuecomment-5698854050, https://github.com/channable/opsqueue/issues/193
We currently have three things that need to happen after a transaction commits:
- Prometheus metrics accounting.
- Notifying via
notify_on_insert. - Notifying via
submission_status_changed(when https://github.com/channable/opsqueue/pull/187 lands).
Ideally we would like to define these actions close to where they most sense on a semantic level (e.g. within insert_submission). However, once transactions come into play this becomes problematic, because these side-effects should only be executed if and when the transaction commits. Since the callee doesn't control, nor has insight in, if and when that commit would happen we have no choice but to defer that execution to the caller. We currently either ignore the problem (for Prometheus metrics), or handle the defer manually (e.g. by returning a bool, and making the caller check that after commit). Both are not ideal.
To remedy this I propose we offer users of opsqueue::db::Connection::transaction() something like the following API:
conn.transaction(move |mut tx| { async move {
...
// Register a callback to run on commit.
tx.on_commit(|| notify_on_insert.notify());
...
} .boxed()}).await?;
To implement that we would have to:
- Store a list of
on_commitcallbacks somewhere on the transaction (TBD where exactly). - Within
opsqueue::db::Connection::transaction()we check if the transaction committed. If so, and we are not in a nested transaction we execute all the callbacks. If we are in a nested transaction we propagate the callbacks upwards.
- 主要言語
- Rust
- スター
- 97
- フォーク
- 2
- 平均マージ
- 1日 18時間
- マージ済み PR（30日）
- 4
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
channable/opsqueue のほかの issue
-
Reserver does not need to be generic対応中かも @jerbaroo が 14 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
channable/opsqueue#195 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Make `submissions_canceled` and `add_chunks_done_to_submissions_failed` migrations bidirectionalオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
channable/opsqueue#193 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
channable/opsqueue の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Y-ASLant/ElegantClipboard#178 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
linxiv-dev/linXiv#384 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug drawings ui
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
userFRM/egui-charts#1595 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
smoltcp-rs/smoltcp#1235 ·
メンテナーはふだん 1 日以内に返信
-
scope:core type:security
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信