feat: [breaking] cmueats gets a real database that can store more than 7 days worth of times, and also stores overwrites

.github/workflows/test.yml

@@ -23,4 +23,6 @@ jobs:
       - name: Install dependencies
         run: pnpm install --frozen-lockfile
       - name: run tests
-        run: pnpm test
+        run: pnpm test:coverage
+      - name: "Report Coverage"
+        uses: davelosert/vitest-coverage-report-action@v2

Dockerfile

@@ -1,3 +1,4 @@
+# this is the file that railway will run
 FROM node:24-slim AS base
 ENV PNPM_HOME="/pnpm"
 # ENV PATH="$PNPM_HOME:$PATH"

README.md

@@ -27,13 +27,13 @@ Now install the API's dependencies by 'cd'-ing into the root of the repository a
 pnpm install
 ```
 
-Start your local database with `pnpm db:start` and then start the server with `pnpm dev` and it should work, assuming you have the correct env variables. (To see the contents of the database, I recommend using DBeaver. You can also run `pnpm db:studio` to start up drizzle studio)
+Start your local database with `pnpm db:start`, `pnpm db:push` (if this is your first time) and then start the server with `pnpm dev` and it should work, assuming you have the correct env variables. (To see the contents of the database, I recommend using DBeaver. You can also run `pnpm db:studio` to start up drizzle studio)
 
 ## Database schema changes (important!)
 
 When you make changes to the database schema, be sure to run `pnpm db:push` to keep your local db in sync.
 
-Before merging your PR, be sure to run `pnpm db:generate` to generate a migration file, which will then be automatically applied to the staging and production databases when deployed.
+Before merging your PR, be sure to run `pnpm db:generate` to generate a migration file, which will then be automatically applied to the staging and production databases when deployed. (You should do this before running tests as well!)
 
 To test if the migration files work, you can run `pnpm run-prod`, which will spin up a production version of the server and a postgres database mounted on a new volume. The server is created using the same Dockerfile used in our Railway deployments, so if it works locally, it (probably) works in production as well.
 

drizzle/0001_broad_lord_tyger.sql

@@ -0,0 +1,57 @@
+CREATE TYPE "public"."specialType" AS ENUM('special', 'soup');--> statement-breakpoint
+CREATE TABLE "concept_id_to_internal_id" (
+	"internal_id" text NOT NULL,
+	"external_id" text PRIMARY KEY NOT NULL,
+	CONSTRAINT "concept_id_to_internal_id_external_id_unique" UNIQUE("external_id")
+);
+--> statement-breakpoint
+CREATE TABLE "location_data" (
+	"id" text PRIMARY KEY NOT NULL,
+	"name" text,
+	"short_description" text,
+	"description" text NOT NULL,
+	"url" text NOT NULL,
+	"menu" text,
+	"location" text NOT NULL,
+	"coordinate_lat" numeric,
+	"coordinate_lng" numeric,
+	"acceptsOnlineOrders" boolean NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE "specials" (
+	"id" integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY (sequence name "specials_id_seq" INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1),
+	"location_id" text NOT NULL,
+	"name" text NOT NULL,
+	"description" text NOT NULL,
+	"date" date NOT NULL,
+	"type" "specialType" NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE "time_overwrites_table" (
+	"location_id" text NOT NULL,
+	"date" date NOT NULL,
+	"time_string" text NOT NULL,
+	CONSTRAINT "time_overwrites_table_location_id_date_pk" PRIMARY KEY("location_id","date")
+);
+--> statement-breakpoint
+CREATE TABLE "location_times" (
+	"id" integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY (sequence name "location_times_id_seq" INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1),
+	"location_id" text NOT NULL,
+	"date" date NOT NULL,
+	"start_time" integer NOT NULL,
+	"end_time" integer NOT NULL
+);
+--> statement-breakpoint
+ALTER TABLE "overwrites_table" RENAME COLUMN "concept_id" TO "location_id";--> statement-breakpoint
+
+-- Manual
+ALTER TABLE "overwrites_table" ALTER COLUMN "location_id" TYPE TEXT, ALTER COLUMN "location_id" SET NOT NULL; --> statement-breakpoint
+-- Manual
+
+ALTER TABLE "concept_id_to_internal_id" ADD CONSTRAINT "concept_id_to_internal_id_internal_id_location_data_id_fk" FOREIGN KEY ("internal_id") REFERENCES "public"."location_data"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
+ALTER TABLE "specials" ADD CONSTRAINT "specials_location_id_location_data_id_fk" FOREIGN KEY ("location_id") REFERENCES "public"."location_data"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
+ALTER TABLE "time_overwrites_table" ADD CONSTRAINT "time_overwrites_table_location_id_location_data_id_fk" FOREIGN KEY ("location_id") REFERENCES "public"."location_data"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
+ALTER TABLE "location_times" ADD CONSTRAINT "location_times_location_id_location_data_id_fk" FOREIGN KEY ("location_id") REFERENCES "public"."location_data"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
+CREATE INDEX "date_lookup" ON "location_times" USING btree ("location_id","date");--> statement-breakpoint
+ALTER TABLE "overwrites_table" ADD CONSTRAINT "overwrites_table_location_id_location_data_id_fk" FOREIGN KEY ("location_id") REFERENCES "public"."location_data"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
+ALTER TABLE "overwrites_table" DROP COLUMN "times";

drizzle/0002_fair_meteorite.sql

@@ -0,0 +1,3 @@
+ALTER TABLE "location_data" RENAME COLUMN "acceptsOnlineOrders" TO "accepts_online_orders";--> statement-breakpoint
+ALTER TABLE "overwrites_table" RENAME COLUMN "coordinateLat" TO "coordinate_lat";--> statement-breakpoint
+ALTER TABLE "overwrites_table" RENAME COLUMN "coordinateLng" TO "coordinate_lng";