feat(app): add app layout and fetch demo data

[vercel[bot]]

@konstantinmuenster is attempting to deploy a commit to the Keeep Team on Vercel.

To accomplish this, @konstantinmuenster needs to request access to the Team.

Afterwards, an owner of the Team is required to accept their membership request.

If you're already a member of the respective Vercel Team, make sure that your Personal Vercel Account is connected to your GitHub account.

[vercel[bot]]

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

Name	Status	Preview	Comments	Updated (UTC)
keeep	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 7, 2024 6:21am

[konstantinmuenster]

@marvin-splitt I resolved the conflicts + manually updated the migration for the Waitlist schema (don't know if that's a good idea or practice 😄).

I'll add the other changes for the layout in a separate PR 👍

[marvin-splitt]

@marvin-splitt I resolved the conflicts + manually updated the migration for the Waitlist schema (don't know if that's a good idea or practice 😄).

I'll add the other changes for the layout in a separate PR 👍

Perfect! But regarding the migration: ideally, you will never ever touch / update migrations manually. 😄 Currently, it's not that crucial as we are in the development / early stage phase and don't have a production that could break but in future cases just create a new migration with the fixed schema, so the history stays intact. Prisma will handle the heavy load under the hood automatically when migrating from different branches.

[marvin-splitt]

By the way @konstantinmuenster, the seed command isn't working anymore on my machine. Can you confirm that, or is it just my fault?

[konstantinmuenster]

@marvin-splitt I resolved the conflicts + manually updated the migration for the Waitlist schema (don't know if that's a good idea or practice 😄). I'll add the other changes for the layout in a separate PR 👍

Perfect! But regarding the migration: ideally, you will never ever touch / update migrations manually. 😄 Currently, it's not that crucial as we are in the development / early stage phase and don't have a production that could break but in future cases just create a new migration with the fixed schema, so the history stays intact. Prisma will handle the heavy load under the hood automatically when migrating from different branches.

I think this time was a bit special. Since your branch didn't have the multi-schema feature enabled, applying the migration to my branch failed. But yeah, in the future we shall avoid it, I agree 😄

the seed command isn't working anymore on my machine. Can you confirm that, or is it just my fault?

What error do you get? It worked fine on my end. Although I once had the issue that the signUp method threw an error. This was fixed by restarting the local supabase instance (reference).

[marvin-splitt]

What error do you get? It worked fine on my end. Although I once had the issue that the signUp method threw an error. This was fixed by restarting the local supabase instance (https://github.com/supabase/gotrue/issues/1061#issuecomment-1502597377).

So the first time running pnpm prisma:migrate I got this error: AuthApiError: Database error finding user. After that error I tried to stop and restart the supabase instance like mentioned in your reference I got another error when starting supabase saying:

{"level":"fatal","msg":"running db migrations: Migrator: problem creating schema migrations: could not execute CREATE TABLE \"schema_migrations\" (\n\"version\" VARCHAR (14) NOT NULL,\nPRIMARY KEY(\"version\")\n);\nCREATE UNIQUE INDEX \"schema_migrations_version_idx\" ON \"schema_migrations\" (version);: ERROR: relation \"schema_migrations\" already exists (SQLSTATE 42P07)","time":"2024-01-06T12:52:37Z"}

Running the supabase start command another time works, but only because supabase probably run a db reset under the hood, as all of my public tables are gone -.- Therefore, running pnpm prisma:migrate another time throws the same error.

I'm so mad right now haha ^^

Have I missed something? Have you tried it with a freshly created supabase instance, or have you just migrated it on your existing schema?

[konstantinmuenster]

What error do you get? It worked fine on my end. Although I once had the issue that the signUp method threw an error. This was fixed by restarting the local supabase instance (supabase/gotrue#1061 (comment)).

So the first time running pnpm prisma:migrate I got this error: AuthApiError: Database error finding user. After that error I tried to stop and restart the supabase instance like mentioned in your reference I got another error when starting supabase saying:

{"level":"fatal","msg":"running db migrations: Migrator: problem creating schema migrations: could not execute CREATE TABLE "schema_migrations" (\n"version" VARCHAR (14) NOT NULL,\nPRIMARY KEY("version")\n);\nCREATE UNIQUE INDEX "schema_migrations_version_idx" ON "schema_migrations" (version);: ERROR: relation "schema_migrations" already exists (SQLSTATE 42P07)","time":"2024-01-06T12:52:37Z"}

Running the supabase start command another time works, but only because supabase probably run a db reset under the hood, as all of my public tables are gone -.- Therefore, running pnpm prisma:migrate another time throws the same error.

I'm so mad right now haha ^^

Have I missed something? Have you tried it with a freshly created supabase instance, or have you just migrated it on your existing schema?

Nope, that's what worked for me 😅 I thought that supabase stop stores the instance state on disk.

But honestly, having worked on the branch left me with the impression that the multi-schema feature is still a bit buggy. I just wasn't sure whether it was my incapability or the feature itself 😂 .. but maybe it would be easier to switch to a single schema with triggers altogether.

[marvin-splitt]

What error do you get? It worked fine on my end. Although I once had the issue that the signUp method threw an error. This was fixed by restarting the local supabase instance (supabase/gotrue#1061 (comment)).

So the first time running pnpm prisma:migrate I got this error: AuthApiError: Database error finding user. After that error I tried to stop and restart the supabase instance like mentioned in your reference I got another error when starting supabase saying:

{"level":"fatal","msg":"running db migrations: Migrator: problem creating schema migrations: could not execute CREATE TABLE "schema_migrations" (\n"version" VARCHAR (14) NOT NULL,\nPRIMARY KEY("version")\n);\nCREATE UNIQUE INDEX "schema_migrations_version_idx" ON "schema_migrations" (version);: ERROR: relation "schema_migrations" already exists (SQLSTATE 42P07)","time":"2024-01-06T12:52:37Z"}

Running the supabase start command another time works, but only because supabase probably run a db reset under the hood, as all of my public tables are gone -.- Therefore, running pnpm prisma:migrate another time throws the same error. I'm so mad right now haha ^^ Have I missed something? Have you tried it with a freshly created supabase instance, or have you just migrated it on your existing schema?

Nope, that's what worked for me 😅 I thought that supabase stop stores the instance state on disk.

But honestly, having worked on the branch left me with the impression that the multi-schema feature is still a bit buggy. I just wasn't sure whether it was my incapability or the feature itself 😂 .. but maybe it would be easier to switch to a single schema with triggers altogether.

Yep, think so too... moreover I am still not a fan of our huge schema file with all these supabase auth entities.. So do you want to tackle this in another PR or do we want to streamline this here before it will be merged into main?

[konstantinmuenster]

What error do you get? It worked fine on my end. Although I once had the issue that the signUp method threw an error. This was fixed by restarting the local supabase instance (supabase/gotrue#1061 (comment)).

So the first time running pnpm prisma:migrate I got this error: AuthApiError: Database error finding user. After that error I tried to stop and restart the supabase instance like mentioned in your reference I got another error when starting supabase saying:

{"level":"fatal","msg":"running db migrations: Migrator: problem creating schema migrations: could not execute CREATE TABLE "schema_migrations" (\n"version" VARCHAR (14) NOT NULL,\nPRIMARY KEY("version")\n);\nCREATE UNIQUE INDEX "schema_migrations_version_idx" ON "schema_migrations" (version);: ERROR: relation "schema_migrations" already exists (SQLSTATE 42P07)","time":"2024-01-06T12:52:37Z"}

Running the supabase start command another time works, but only because supabase probably run a db reset under the hood, as all of my public tables are gone -.- Therefore, running pnpm prisma:migrate another time throws the same error. I'm so mad right now haha ^^ Have I missed something? Have you tried it with a freshly created supabase instance, or have you just migrated it on your existing schema?

Nope, that's what worked for me 😅 I thought that supabase stop stores the instance state on disk. But honestly, having worked on the branch left me with the impression that the multi-schema feature is still a bit buggy. I just wasn't sure whether it was my incapability or the feature itself 😂 .. but maybe it would be easier to switch to a single schema with triggers altogether.

Yep, think so too... moreover I am still not a fan of our huge schema file with all these supabase auth entities.. So do you want to tackle this in another PR or do we want to streamline this here before it will be merged into main?

I'd say we should fix this in here before merging 👍 Maybe I find some time this evening to fix it once and for all. But if it blocks you right now and you want to fix it right away, feel free to do so.

[konstantinmuenster]

@marvin-splitt I just removed the multi-schema feature and started from a blank slate. Should work fine on staging and local now 😄

[marvin-splitt]

@marvin-splitt I just removed the multi-schema feature and started from a blank slate. Should work fine on staging and local now 😄

Noice! I will have a look and try it out (fingers crossed) 😄