Self-hosting migration fails if not using the default "public" schema

[swag42dev]

trigger.dev/apps/webapp/app/presenters/JobListPresenter.server.ts

Line 125 in 336029b

"public"."JobRun"

[swag42dev]

code: 'P2010',

clientVersion: '5.4.1',

meta: { code: '42P01', message: 'relation "public.JobRun" does not exist' }

}

[swag42dev]

and migration which fails if project hosted in custom schema eg "triggerdotdev"
CREATE INDEX idx_jobrun_jobId_createdAt ON "public"."JobRun" ("jobId", "createdAt" DESC);

[matt-aitken]

Good spot, a fix for this has been pushed to main. I'm creating another latest build right now, should be available in 10 mins to use.

[matt-aitken]

Ah shit I didn't spot the migration

[matt-aitken]

@swag42dev unfortunately it's not going to be easy to fix that migration. It's already been applied and just editing the file isn't an option as that causes an out-of-sync issue which would wipe everyone's databases when deploying.

There are complicated options Prisma offers but I'm not clear on the best approach at the moment.

I think you can manually resolve for yourself by doing this:

1. Run this on your database, it will mark that migration as done (even though it isn't):

prisma migrate resolve --applied "20240130165343_add_composite_index_to_job_run_for_job_id_and_created_at"

2. Manually perform the SQL migration to create the composite index:

CREATE INDEX idx_jobrun_jobId_createdAt ON "JobRun" ("jobId", "createdAt" DESC);

Sorry about this. That migration was auto-generated by Prisma when I used their @@Index notation… 😠

[swag42dev]

@matt-aitken no problem. i already fix migration. thank you for quick fix

[brentshulman-silkline]

This is and extremely annoying and causing issues with deploying on ECS that:

1. Make the docs incorrect
2. Means I need to deploy a separate db

[matt-aitken]

There's a more up to date issue on this with a better temporary fix: #1026