"When was this customer last in" and "did they buy" are one question staff ask in one breath, and answering it meant two calls and a join in the client. Each visit row carries purchases, spend and currency. LATERAL, not a join onto purchases. A plain join returns the visit TWICE when it holds two sales, which would make a customer look like they came more often than they did - a wrong number of exactly the kind this product is otherwise careful about, arrived at by adding a feature. Mixed currencies on one visit report the count and NO figure. Adding rupees to dollars produces something that looks like money and is not, and the sales still happened, so the count is the honest part to keep. A purchase with no visit_id is deliberately absent: it belongs to the customer rather than to a moment, and GET /api/sales?customer=V-42 lists it. The two surfaces together cover every sale exactly once. Both properties are asserted in the LIVE store tests, because both live in the SQL. An in-memory fake asserting that a LATERAL does not duplicate a row would only be checking the fake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
13 KiB
13 KiB