Fix for frontpage table refactoring

[berekuk]

(continuing from #67, turns out GH doesn't allow reopening PRs...)

Ok, I'm not sure what happened, but #67 broke prod. I'm opening this just to leave this postmortem note, and to check the code before merging to master.

My original approach went like this:

  const questions = await prisma.frontpageId.findMany({
    include: {
      question: true,
    }
  });

Prisma generated a weird query, which I noticed but decided that it's not a big deal (notice the triple negations):

SELECT "public"."questions"."id", "public"."questions"."title", "public"."questions"."url", "public"."questions"."platform", "public"."questions"."description", "public"."questions"."options", "public"."questions"."timestamp", "public"."questions"."stars", "public"."questions"."qualityindicators", "public"."questions"."extra" FROM "public"."questions" WHERE (NOT ("public"."questions"."id") NOT IN (SELECT "public"."FrontpageId"."id" FROM "public"."FrontpageId" WHERE "public"."FrontpageId"."id" IS NOT NULL)) OFFSET $1

It worked on my machine for my local dev db but collapsed in prod.

Anyway, when I went to debug it I noticed that it also wasn't keeping the random order because I selected questions which had frontpage ids, which sorted the questions in the natural questions order.

So now I'm doing it in reverse: select for frontpage ids and ask Prisma to add questions data to it.

This causes two queries instead of one:

prisma:query SELECT "public"."FrontpageId"."id" FROM "public"."FrontpageId" WHERE 1=1 OFFSET $1
prisma:query SELECT "public"."questions"."id", "public"."questions"."title", "public"."questions"."url", "public"."questions"."platform", "public"."questions"."description", "public"."questions"."options", "public"."questions"."timestamp", "public"."questions"."stars", "public"."questions"."qualityindicators", "public"."questions"."extra" FROM "public"."questions" WHERE "public"."questions"."id" IN ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50) OFFSET $51

But it shouldn't be a problem.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
metaforecast	✅ Ready (Inspect)	Visit Preview	Apr 22, 2022 at 8:51PM (UTC)

[berekuk]

No, that's not it, it still responds with 500. But only on Vercel, it works on my machine even if I point it to the prod DB. Weird.

[berekuk]

Oh.

ERROR   ReferenceError: prisma is not defined
    at getFrontpage (/var/task/.next/server/pages/api/graphql.js:75:23)

Which should've been caught by typescript... except that there's this code from Prisma's "Best practice for dev" page which recommends putting prisma in global, but in dev only. Ugh.

• I renamed global.prisma to global._prisma to avoid future issues like this
• also, turns out debugging graphql exceptions is annoying because graphql/pothos just hides them and doesn't log them anywhere in prod; I'll look into how to fix this (maybe just enable exceptions in prod since our code is public and it's probably safe; or maybe look into pothos plugins for this or write my own)