FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
同期schemaとdatabase migrationの責務を分ける
ConnectorをruntimeとEdge Functionへ絞り、database変更の正本を一か所へ集約する
目的
同じdatabase projectへ対するmigrationが、同期runtime側と表示アプリ側の両方に置かれていた。別々に適用すると履歴の順序と、どちらがdatabase構造へ責任を持つかが曖昧になる。
同期dataを専用schemaへ移したうえで、database migrationの追加・reset・適用は一つの正本だけから行い、Connector側は同期runtimeとEdge Functionの実装・運用へ責務を限定することを目指した。
実装
同期clientのhealth checkをcodex schemaへ向け、database objectをpublic前提で探さないようにした。同期runtimeが参照するtableとRPCのschemaを明示し、新しいdatabase境界へ揃えた。
- 限定ingestion endpointはbatch取込RPCを
codexschemaから呼ぶ。 - heartbeat endpointもdevice heartbeat RPCを同じschemaから呼ぶ。
- Edge Functionの認証とowner境界は維持し、参照先schemaだけを新しい配置へ合わせた。
Connector側に重複していたdatabase migrationを削除し、database変更セットでこのdirectoryがmigration適用元ではないことを明記した。database migrationの追加、local reset、remote適用は表示アプリ側の正本から実行する。
database runtime設定は共有するlocal Supabase project構成へ合わせた。Connector側はEdge Functionをserve・更新できるが、database lifecycle scriptを所有しない構成にし、同じprojectへ2本のmigration履歴を作らないようにした。
- security guideはschema別の権限とruntime境界を更新した。
- database setup guideはdatabase作業とEdge Function作業の実行元を分けた。
- 統合手順書とproject guideは共有projectと継続同期の手順を新しい責務へ揃えた。
型検査、test、buildに加えて診断と単発同期を実行し、2つのEdge Functionを新しいschema参照で確認した。remote databaseでRPC呼出しと継続同期が動くことも検査した。
Connector側はruntime参照だけを持ち、database migrationの履歴は一つのownerへ集約した。runtime queryは対象schemaを明示するよう変更した。
図を描画しています…
確認したこと
確認結果
TypeScript型検査、38件のtest、production buildを含むcheckが成功した。
診断と単発同期が新しいcodex schema参照で成功した。
2つのEdge Functionはremote側で更新され、対応するRPCを新schemaから呼び出した。
重複migrationはConnector側から取り除かれ、database lifecycleとruntimeの担当が文書・script・設定で一致した。
cutoff時点でschema参照とmigration責務の整理は対象へ反映され、remoteで継続同期を確認した。database migrationの内容自体と表示アプリ側の公開・管理境界は別の作業範囲である。
完了とした根拠
runtimeとEdge Functionのschema参照が揃い、重複migrationとdatabase lifecycle scriptを外し、文書化した単一のmigration正本でremote同期確認まで通った内容が対象へ反映されたことをもって完了とした。