Exercise 3: Why the Date Math Happens in JavaScript Here — Possible Solution
====================================================================

WHY IT'S COMPUTED IN JAVASCRIPT INSTEAD OF INSIDE THE QUERY
------------------------------
SQLite has its own built-in date() function, which the sibling course
uses directly inside its SQL string to compute "three days from today"
as part of the query itself - date('now', '+3 days'). Prisma Client's
own query methods don't expose a general way to run arbitrary
database-side date-arithmetic functions like this as part of a where
clause; a query built through Prisma's API is constructed from plain
JavaScript values passed in as parameters. So the equivalent
calculation - adding three days to the current time - has to happen in
ordinary JavaScript before the query is built, producing a real Date
object that gets passed in as the lte value.

ONE REAL CONSEQUENCE OF COMPUTING IT THIS WAY
------------------------------
Because the calculation is plain JavaScript rather than a SQLite-
specific function call, it isn't tied to SQLite's own date()
dialect at all - the exact same threeDaysFromNow calculation would
work unchanged if this app's database were swapped for PostgreSQL or
MySQL under Prisma, since Prisma's own query API stays the same across
providers. The sibling's date('now', '+3 days') call, by contrast, is
specific to SQLite's own SQL dialect and would need rewriting if the
underlying database ever changed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that Prisma's query API takes JavaScript values
rather than embedding database-specific functions in a query string,
and it names a genuine, concrete consequence (portability across
database engines) rather than treating the JavaScript-vs-SQL location
of the calculation as an arbitrary stylistic difference.