# マイグレーションと型 スキーマを変更する SQL を**バージョン付きのファイル**として残しておくと、同じ変更をほかのプロジェクト（ステージング → 本番）に 同じ順序で適用し直せます。`run_sql` で変更したものは記録が残りません。 ``` list_migrations 適用したマイグレーションのバージョン・名前・時刻（古い順） apply_migrations まだ適用していないものだけをバージョン順に実行し、記録します remove_migration_record 記録を1つ削除します（作られたものはそのまま） dump_schema 今のスキーマを作り直せる SQL として generate_typescript_types supabase-js の Database 型 ``` ## 適用のされ方 - マイグレーション1つが**トランザクション1つ**です。失敗すると、そのマイグレーションだけをまるごと元に戻して止まります。 前のものは適用されたまま残り、後のものは実行しません。 - バージョンは数字で（通常は `YYYYMMDDHHMMSS`）、数値の大きさの順に実行します。すでに記録されたバージョンは飛ばします。 - すでに適用された最後のバージョンより**前の**バージョンが新しく来ると拒否します。あとから統合したブランチなら `include_all: true` です。 - 記録されたあとで内容が変わったファイルは再実行せず、`drifted` として知らせます。直すには新しいマイグレーションを書いてください。 - `run_sql` と同じ権限（書き込みトークン、オーナー・管理者・開発者）で、プロジェクトの service_role として実行します。 テーブルを作ると RLS が有効になるのも同じです。1つのマイグレーションは60秒を超えられません。 - データスキーマが search_path の先頭にあるため、`create table notes (...)` のように名前だけを書けば十分です。 ## 記録はどこに プロジェクトの `oneend_migrations` テーブルです。オーナーは SQL で読めます。RLS が有効でルールがないため、公開キーでは見えません。 `supabase_migrations.schema_migrations` と同じ役割です。 ## スキーマをファイルに、型をコードに `dump_schema` は、型・シーケンス・テーブルと制約・外部キー・インデックス・関数・ビュー・トリガー・RLS とルールを SQL で返します。 既存のプロジェクトをマイグレーションで管理し始めるときは、これを最初のマイグレーションとして保存し、 `apply_migrations` に `record_only: true` を付けて記録だけを残してください。実行すると、すでにあるテーブルとぶつかります。 `generate_typescript_types` は `supabase gen types typescript` と同じ形（Tables の Row/Insert/Update/Relationships、 Views、Functions の Args/Returns、Enums、CompositeTypes）を返します。スキーマ名は `public` です。 ## 同じことを HTTP で ``` GET /projects//migrations POST /projects//migrations {migrations: [{version, name, sql}], include_all, record_only, dry_run} DELETE /projects//migrations/ GET /projects//schema {sql, objects} GET /projects//types/typescript?schema=public {types} ``` --- https://end.blackall.ai/docs/migrations?lang=ja