Record each run of a v2 simulation and report, and key results by run

未關閉
#4,161 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 2 天內回覆

@anth-volk 已經在處理了。

開始於 2026年11月3日。

  • #4162 來自 @anth-volk —— 未關閉

評估

難度
5/5
預估耗時
一週以上
新手友好度
12/100
Issue 類型
重構
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
postgresql, python, supabase
領域
database

研究方向

The v2 simulation tables live in the Supabase database, so start with the schema migrations that create simulations, reports, report_runs and household_jobs, and the result tables they feed. The issue asks for a new simulation_runs table, a join record between report runs and simulation runs, and role grants for two new database roles, so the migration needs to apply cleanly before the roles exist. Done means the migration applies on a fresh database, existing rows are kept, and no foreign keys cross from the simulation API tables to the Public API tables.

由索引模型根據 Issue 內容生成。

描述

API v2's simulation tables in the v2 Supabase database (simulations, reports, report_runs, household_jobs and the result tables) were designed for an execution model where each simulation ran once. We now want every run of a simulation or a report saved, with the PolicyEngine.py and country package versions it used, so a re-run keeps the earlier results, and the simulation API and its Modal workers will write these rows themselves.

What needs to change in the v2 schema:

  • a simulation_runs table: one row per run of a simulation, with its versions, status, Modal call and output file, instead of execution columns on simulations;
  • a record of which simulation runs each report run combines, so a budget window's run can combine one pair per year;
  • result rows keyed by the run that produced them;
  • household_jobs shaped for one household, one year and one policy, with its versions and Modal call;
  • no foreign keys between the tables the simulation API writes and the tables the Public API writes: each service checks the rows it refers to;
  • table privileges for two new database roles, one for the simulation API and one for its Modal workers, declared so the deploy can apply them once an operator has created the roles, without failing before then.

No table is dropped.

主要語言
Python
星號
18
分支
33
平均合併
2 天 21 小時
30 天內合併 PR
93

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

PolicyEngine/policyengine-api 的其他 Issue

查看 PolicyEngine/policyengine-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。