supabase
fix(migrations): update types that are not set on the schema
What kind of change does this PR introduce?
This changeset updates the migrations schema that's causing trouble on new supabase/auth installations whether it's using docker or not. The types are not set on the schema which causes the migrations to fail. And it adds residual types to public schema.
What is the current behavior?
Issue #1729 was closed despite not resolving the problem.
What is the new behavior?
Add the relevant types to the proper schema.
Additional context
It seems the main problem here is the migrator-cmd executes the sql migrations in public schema. That's why when the next sql instruction comes up, it tries to find it in public and that's the reason it fails. That's why I force the schema migrations to use the namespace types.
Would be nice if this merge request would fix the migration errors. Right now it is not possible for me to start a new docker container because i get always an error that the factor_type doesn't exists.
I can only fix it by manually creating that type in the DB.
So this migration ist the problem in my case: 20240729123726_add_mfa_phone_config.up.sql
Pull Request Test Coverage Report for Build 12053898208
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 0 of 0 changed or added relevant lines in 0 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage remained the same at 56.998%
| Totals | |
|---|---|
| Change from base Build 12045179447: | 0.0% |
| Covered Lines: | 9546 |
| Relevant Lines: | 16748 |
💛 - Coveralls
@patrickwjh you might need to create the auth user before doing the migration and set its search path to auth or your custom DB_NAMESPACE.
This PR only solves the problem like if the auth user is not created before doing the migration and that would result in the above screenshots which scatters the types to default schema. A scenario where user will move all created item ownership to auth user afterwards (after running the migration).