From afdc8ec703d351cf386d7c94e10cfcda6087ad05 Mon Sep 17 00:00:00 2001 From: Khalim Conn-Kowlessar Date: Wed, 22 Apr 2026 10:10:34 +0000 Subject: [PATCH] commenting unintuitive sql query --- .../scenario/[scenarioId]/metrics/route.ts | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/app/api/portfolio/[portfolioId]/scenario/[scenarioId]/metrics/route.ts b/src/app/api/portfolio/[portfolioId]/scenario/[scenarioId]/metrics/route.ts index 5760a33..8fc292b 100644 --- a/src/app/api/portfolio/[portfolioId]/scenario/[scenarioId]/metrics/route.ts +++ b/src/app/api/portfolio/[portfolioId]/scenario/[scenarioId]/metrics/route.ts @@ -132,10 +132,16 @@ export async function GET( )::float AS total_sap_uplift FROM latest_plans lp JOIN property p ON p.id = lp.property_id + -- Conditional filter: only restrict by original_sap_points when the toggle is on + -- AND the scenario has an EPC target. Written as an OR chain so Postgres evaluates + -- it as a single WHERE clause — avoiding the need to dynamically build the query + -- string in application code (which would require string concatenation and risks + -- SQL injection). The OR short-circuits left-to-right: if the first or second + -- condition is true, the third is never evaluated, so all rows pass through. WHERE ( - ${useOriginalBaseline} = false - OR ${minSap}::float IS NULL - OR p.original_sap_points < ${minSap}::float + ${useOriginalBaseline} = false -- toggle off → include everything + OR ${minSap}::float IS NULL -- no EPC target → nothing to filter on + OR p.original_sap_points < ${minSap}::float -- actual filter ); `);