From d42706d4e59621cceed19041abeb10a76044b6e5 Mon Sep 17 00:00:00 2001 From: Cal Corum Date: Tue, 3 Mar 2026 21:18:19 -0600 Subject: [PATCH] =?UTF-8?q?store:=20PR=20review:=20paper-dynasty-database#?= =?UTF-8?q?52=20=E2=80=94=20consolidate=20double-query=20in=20get=5Fone=5F?= =?UTF-8?q?play?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...abase52-consolidate-double-query-c9b2c0.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 graph/workflows/pr-review-paper-dynasty-database52-consolidate-double-query-c9b2c0.md diff --git a/graph/workflows/pr-review-paper-dynasty-database52-consolidate-double-query-c9b2c0.md b/graph/workflows/pr-review-paper-dynasty-database52-consolidate-double-query-c9b2c0.md new file mode 100644 index 00000000000..539611b35e3 --- /dev/null +++ b/graph/workflows/pr-review-paper-dynasty-database52-consolidate-double-query-c9b2c0.md @@ -0,0 +1,26 @@ +--- +id: c9b2c04d-258a-4028-849b-a47f6168a6ab +type: workflow +title: "PR review: paper-dynasty-database#52 — consolidate double-query in get_one_play" +tags: [pr-reviewer, paper-dynasty-database, peewee, query-optimization, fastapi] +importance: 0.4 +confidence: 0.8 +created: "2026-03-04T03:18:19.838537+00:00" +updated: "2026-03-04T03:18:19.838537+00:00" +--- + +## PR #52 — fix: consolidate redundant double-query in get_one_play + +**Verdict**: APPROVED (posted as COMMENT due to Gitea self-review restriction) +**File**: `app/routers_v2/stratplays.py` + +### Change Summary +`get_one_play` was calling `get_or_none` (discarding the result) then `get_by_id` to fetch the same record again. Fix stores the `get_or_none` result and passes it directly to `model_to_dict`, eliminating the redundant second query. + +### Key Findings +- Correct: `get_or_none` returns the model instance or None — reusing it is semantically identical +- No security issues — unauthenticated GET, int-typed param +- Clean, minimal change following project conventions + +### Follow-up Note +`patch_play` at ~line 1412 has the same double-query pattern and should be fixed in a follow-up issue.