本文へ移動
cccskills
無料GitHub で公開日本語紹介

update-sqlx

RustコードでSQLクエリを追加・変更した際に、SQLxのオフラインキャッシュを安全に更新する手順を案内します。既存のキャッシュを保全し、テスト対象も含めて検証する方法を確認できます。

原文原文の説明を見る

How to safely update SQLx offline query cache. MUST use when SQL queries change.

windmill-labs/windmillスター 18,276(GitHub 18,276 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • SQLクエリ変更後にキャッシュを更新したいとき
  • テスト内のクエリもキャッシュしたいとき
  • 既存のオフラインキャッシュを保全したいとき
  • CIのSQLxキャッシュエラーを防ぎたいとき

日本語での紹介

できること

RustコードのSQLクエリを追加・編集したときに、SQLxのオフラインクエリキャッシュを安全に更新する手順を示します。更新前のバックアップ、対象ワークツリーのデータベース指定、生成後の欠落確認を行い、既存のエンタープライズ向けキャッシュを誤って消さないようにします。テスト内のクエリは通常のワークスペース確認だけではキャッシュされないため、テスト対象を含む確認方法や、Community Edition環境で生成が途中終了した場合に必要な復元手順も説明します。クエリを削除しただけの変更では、キャッシュ生成を実行しない判断も案内します。

こんなときに便利

SQLクエリの追加・編集後、CIでオフラインキャッシュ不足のエラーを出さないよう準備したいときに使えます。複数のワークツリーやCommunity Edition環境で作業し、キャッシュの消失や誤ったデータベース参照を避けたい場合にも役立ちます。

使い方の例

  • 「追加したSQLクエリのSQLxキャッシュを安全に更新する手順を教えてください」
  • 「テスト内のクエリも含めて、キャッシュの確認方法を案内してください」

注意点

Rust、SQLx、Cargo、Bashを使うリポジトリ向けの手順です。クエリ生成時は対象ワークツリーのライブデータベースを指すDATABASE_URLが必要です。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(2)

  • SKILL.md6.8 KB
  • sqlx-cache.sh2.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

SQLx Offline Query Cache

Windmill uses SQLX_OFFLINE=true in CI, which requires all sqlx::query! / sqlx::query_as! macros to have matching cached query data in backend/.sqlx/.

When to Run

Run after adding or editing a SQL query in Rust source. Without it, CI fails with:

error: `SQLX_OFFLINE=true` but there is no cached data for this query

Do NOT run it when a change only removes queries. The cache is already complete for CI; all that is left are orphaned entries, which are cosmetic and never break a build. Running prepare to tidy them risks destroying the cache for no gain. Delete them offline instead: for each .sqlx/query-*.json, normalize its query field (strip \ line-continuations, collapse whitespace) and check whether it still appears in any .rs file. That detector reports ~48 false positives in a CE checkout — EE queries live in *_ee.rs symlinks it cannot read — so filter to the tables your change touched and delete only those.

Before You Run Anything

  1. Back the cache up. prepare deletes .sqlx/ before regenerating, so any compile failure leaves it gutted (observed: 2350 → 142 entries).
    bash .agents/skills/update-sqlx/sqlx-cache.sh backup
    
    Its state is per-worktree, so a sibling worktree running prepare at the same time cannot overwrite your backup.
  2. Point DATABASE_URL at THIS worktree's database. prepare compiles every sqlx::query! against the live database. Another worktree's DB lacks your migrations, so every new-table query fails and takes the cache down with it. The symptom is relation "<your_new_table>" does not exist — that is a wrong DATABASE_URL, not a broken query. See AGENTS.md → "Per-worktree ports and database".

Queries Inside Tests Need --all-targets, Which Fails In A CE Checkout

prepare only caches queries in code it compiles, and --workspace alone does not compile test targets. A sqlx::query! inside tests/*.rs therefore gets no entry, and CI fails on the test target with the usual "no cached data" error even though the lib built clean. SQLX_OFFLINE=true cargo check --workspace --all-targets is what reproduces it.

Adding --all-targets caches them — and, in a CE checkout, aborts partway through: backend/tests/otel.rs imports windmill_common::otel_ee, which exists only behind the private feature, so the compile dies after prepare has already emptied .sqlx/. Observed: 2435 → 4 entries, error: cargo check failed with status: exit status: 101.

Do not fight it — the abort is a pre-existing EE gap, not something your change caused. Take the entries you need and put the backup back:

bash .agents/skills/update-sqlx/sqlx-cache.sh backup

cd backend
DATABASE_URL=<this worktree's db> \
  cargo sqlx prepare --workspace -- --workspace --features all_sqlx_features --all-targets
# expected to fail; it still wrote the entries it got to before dying
cd ..

bash .agents/skills/update-sqlx/sqlx-cache.sh newq      # prints each added query
bash .agents/skills/update-sqlx/sqlx-cache.sh restore   # backup back, added entries grafted on

Read what newq prints before running restore — it shows each added entry's query field, and every one should be yours. The set is small (one per new test query); anything else in there means the run got further than you think.

Then verify both targets, since the lib passing says nothing about the tests:

SQLX_OFFLINE=true cargo check --workspace --features all_sqlx_features   # lib
SQLX_OFFLINE=true cargo check -p <your-crate> --all-targets              # tests

The Problem

cargo sqlx prepare --workspace deletes all existing cache files and regenerates only the ones found in the current compilation. If you don't compile with every feature flag (especially private for EE files), you will silently delete EE query caches, breaking CI for enterprise tests.

The standard ./update_sqlx.sh script tries to compile with all features, but it often fails locally because the EE symlinks can be out of sync with main.

Safe Procedure

Always preserve the existing EE caches from origin/main. Use this workflow:

cd backend

# 1. Restore the full cache from main (includes EE caches)
git checkout origin/main -- .sqlx/

# 2. Run prepare with OSS features (what compiles locally)
#    This regenerates OSS caches to match your code changes.
cargo sqlx prepare --workspace -- --workspace --features all_sqlx_features

# 3. Restore any EE caches that were deleted in step 2.
#    These are files present in origin/main but missing after prepare.
git ls-tree origin/main backend/.sqlx/ \
  | awk '{print $4}' | sed 's|backend/\.sqlx/||' | sort > /tmp/main_files.txt

find backend/.sqlx -name "*.json" -printf '%P\n' | sort > /tmp/current_files.txt

comm -23 /tmp/main_files.txt /tmp/current_files.txt > /tmp/missing_files.txt

while read f; do
  git show "origin/main:backend/.sqlx/$f" > "backend/.sqlx/$f"
done < /tmp/missing_files.txt

# 4. Verify nothing was lost from main
find backend/.sqlx -name "*.json" -printf '%P\n' | sort > /tmp/current_files.txt
comm -23 /tmp/main_files.txt /tmp/current_files.txt | wc -l
# Should output: 0

If EE Compiles Locally

If your EE repo happens to be in sync, you can use the full script (faster):

cd backend
./update_sqlx.sh

But if it fails with EE compilation errors, use the safe procedure above.

What NOT to Do

  • Never run cargo sqlx prepare --workspace with only OSS features and commit the result — it will delete EE caches.
  • Never set SQLX_OFFLINE=true for local cargo sqlx prepare — use a live database per CLAUDE.md. (CI runs with SQLX_OFFLINE=true, which is why the cache must be complete.)
  • Never run prepare without a .sqlx backup, or against a DATABASE_URL you have not confirmed belongs to this worktree.
  • Never run prepare at all for a removal-only change.
  • Never skip the verification step (step 4 above).
  • Never leave a --all-targets run's output in place after it aborts — it is a near-empty cache. Restore the backup and graft on only the entries you verified.

Step 4 compares against origin/main because step 1 restored from it, so the two agree. If you did not run step 1 — auditing a branch's cache on its own, say — compare against git merge-base HEAD origin/main instead: origin/main advances, so its newer entries would read as losses on your branch.

Verification

After committing, the diff against origin/main should show:

  • A few new cache files (for your changed queries)
  • A few deleted cache files (for old queries that no longer exist)
  • Zero net deletions from the EE cache set
git diff origin/main --stat backend/.sqlx/

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

adding-a-trigger

無料概要あり

Windmillに新しいTriggerCrud型のトリガーを追加する際、バックエンドからCLI、画面、同期やキャプチャ機能まで必要な変更箇所を確認できる開発チェックリストです。

  • 新しい外部サービスのトリガーを追加したいとき
  • 実装箇所の抜け漏れを点検したいとき
  • トリガー追加のPR前に検証したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

ai-chat

無料概要あり

WindmillのAIチャットを変更するときに、ツールやプロンプト、結果の返し方、コンテキスト量を整理し、評価で変更前後の挙動を比べるための指針です。

  • チャットツールを変更したいとき
  • プロンプトの配置を見直したいとき
  • コンテキスト消費を抑えたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

ai-evals

無料概要あり

WindmillのAI生成モード向けに、実際の利用要求に沿ったベンチマークケースを作成・実行します。生成結果を決定的な検証とLLM評価で確認し、AIチャットやcopilotの変更前後を比較できます。

  • AI生成モードの評価ケースを追加したいとき
  • AIチャットの変更前後を比較したいとき
  • copilotの生成品質を確認したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

cli-commands

無料概要あり

Windmill CLIのコマンドを使い、スクリプトやフローなどの管理、ジョブの実行履歴確認、失敗原因の調査を進めるためのリファレンスです。

  • 失敗したジョブの原因を調べたいとき
  • 実行履歴やジョブログを確認したいとき
  • CLIでスクリプトやフローを管理したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

codebase-design

無料概要あり

モジュールのインターフェースを小さく保ちながら、内部に複雑な処理をまとめる設計を支援します。テストしやすさや変更のしやすさを考え、処理の境目を整理できます。

  • モジュールのインターフェースを設計したいとき
  • 既存モジュールの複雑さを整理したいとき
  • 処理を差し替える境目を決めたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

commit

無料概要あり

変更内容を確認し、対象ファイルだけを選んで、形式や長さの規則に沿ったConventional Commits形式のGitコミットを作成するスキルです。

  • 機能追加をコミットしたいとき
  • バグ修正を記録したいとき
  • 変更内容に合うコミット文を作りたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

windmill-labs のスキルをすべて見る

このスキルの問題を報告する