supabase
0012_add_updated_at.sql hardcodes role name to postgres
https://github.com/supabase/stripe-sync-engine/blob/2c0d81aaf877af018d1d4f103459e24cffebeca2/db/migrations/0012_add_updated_at.sql#L11
If the database does not have a postgres role, the migration fails.
/app/node_modules/pg-node-migrations/dist/migrate.js:108
const error = new Error(`Migration failed. Reason: ${e.message}`);
^
Error: Migration failed. Reason: An error occurred running 'add_updated_at'. Rolled back this migration. No further migrations were run. Reason: role "postgres" does not exist
# shell
sed -i -e '/owner to postgres/d' db/migrations/0012_add_updated_at.sql && npm start
# docker run
/bin/sh -c "sed -i -e '/owner to postgres/d' db/migrations/0012_add_updated_at.sql && npm start"
overwrote the docker run command to remove that line.
Unfortunately fixing this at the root will involve rewriting the migrations which won't work with the current migration library as checksums would differ and migrations would fail. I think the best solution is to move away from the current migration library and just do custom migrations (backwards compatible). This will also allow us to clean up some older migrations that have hard-coded things that we'd like to change, but cannot in the current migrations.
same issue here. was trying to specify a custom schema by changing the schame variable name but it always fails on migration
Unfortunately with the current migration setup, modifying these migrations is not possible, as this will cause a different checksum and fail migrations for any existing users. You can copy the migrations into your own migration flow and not rely on the Stripe Sync Engine to do migrations to get around that.
hi @kevcodez , thanks for the reply. I am trying to start from scratch with a custom schema, but even if I hardcode migrations, all the other tables are not generated. Do you know what might be the workaround?
Great project btw! Incredible time savings
@pedrojrv You can copy over all the migrations to your own migration flow (whichever you're using) and simply not let the stripe-sync-engine do any migrations. You can still in a custom schema when initiating the client, so the client itself is compatible with a custom schema. Only the out-of-the-box migrations are fixed to the stripe schema, but you don't have to use the built-in migration tooling.
One thing you would have to do in this case is check if there are new migrations when updating the stripe sync engine, as you would have opted out of the built-in migrations.