Supabase: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 50: | Zeile 50: | ||
Siehe https://stackoverflow.com/questions/73281996/how-to-access-custom-schema-from-supabase-js-client | Siehe https://stackoverflow.com/questions/73281996/how-to-access-custom-schema-from-supabase-js-client | ||
+ | Da es die API Settings im lokalen Supabase wohl nicht gibt, muss man durch [https://github.com/orgs/supabase/discussions/6682 einen Workaround das Schema freigeben]: | ||
+ | |||
+ | alter role authenticator set pgrst.db_schemas = 'public, storage, sharebudget'; | ||
+ | select pg_notify('pgrst', 'reload config'); | ||
+ | select pg_notify('pgrst', 'reload schema'); | ||
Beim Nutzen von supabase db diff ist es dann meist sinnvoll, den --schema (-s)-Parameter zu setzen. | Beim Nutzen von supabase db diff ist es dann meist sinnvoll, den --schema (-s)-Parameter zu setzen. |
Aktuelle Version vom 27. Mai 2023, 21:53 Uhr
Supabase ist ein Cloud-Service, der insbesondere eine Postgres-Datenbank beinhaltet, aber auch Storage und Serverless Functions.
Laufenlassen auf dem lokalen Rechner
Supabase läuft (fast) genauso wie in der hosted Version auf supabase.com auch auf dem lokalen Rechner.
Es lässt sich z.B. mit npx folgendermaßen starten
npx supabase start
Dann richtet es etliche Docker-Container ein, auch manche die man nicht braucht. Man kann die Container, die man nicht braucht, mit der --exclude
-Option deaktivieren.
Dazu setzt man alle nicht benötigten Container ohne Leerzeichen, aber mit Kommata getrennt hinter die Option:
npx supabase start --exclude "gotrue,realtime,storage-api,imgproxy,kong,inbucket,postgrest,pgadmin-schema-diff,migra,postgres-meta,studio,deno-relay"
In dem Fall läuft dann tatsächlich nur Postgres. Will man doch ein bisschen arbeiten, könnte folgender Befehl passen:
npx supabase start --exclude "realtime,storage-api,imgproxy,inbucket,pgadmin-schema-diff"
gotrue
ist für den API-Key notwendig. Dieser wird beim Start von supabase sonst nicht angezeigt.
Mit
npx supabase stop
hält man die lokalen Container an.
Verbindung mit hosted Supabase
npx supabase login npx supabase link
Übernehmen des Inhalts der Remote-Database in die lokale Umgebung
npx supabase db remote commit npx supabase db reset
Änderungen der lokalen Umgebung in die Hosted Database
Zunächst Änderungen in der lokalen Datenbank vornehmen und dann diese Änderung in einer "Migration" speichern:
npx supabase db diff --file $DIFF_FILE_NAME
Schließlich diese Migration auf supabase.com "pushen":
npx supabase db push --dry-run npx supabase db push
Troubleshooting
Zugriff auf eigenes Schema / Namespace
Siehe https://stackoverflow.com/questions/73281996/how-to-access-custom-schema-from-supabase-js-client
Da es die API Settings im lokalen Supabase wohl nicht gibt, muss man durch einen Workaround das Schema freigeben:
alter role authenticator set pgrst.db_schemas = 'public, storage, sharebudget'; select pg_notify('pgrst', 'reload config'); select pg_notify('pgrst', 'reload schema');
Beim Nutzen von supabase db diff ist es dann meist sinnvoll, den --schema (-s)-Parameter zu setzen.
Siehe zur lokalen Entwicklung mit Schema auch: https://github.com/orgs/supabase/discussions/10428
Backup der Postgres-Database
Zum Backup nutzt man das Standard-Postgres-Tool pg_dump.
Siehe
Serverless Functions
Bei Supabase heißen die Serverless Functions "Edge Functions". Es sind Funktionen, die in TypeScript geschrieben werden und in der Nodejs-Alternative Deno laufen.
Daneben sind die normalen Postgres-Funktionen auch möglich. Sie sind aus Performance-Gründen bei Daten-gestützten Aufgaben zu bevorzugen. Siehe dazu
Siehe zu Edge Functions:
- https://deno.com/blog/supabase-functions-on-deno-deploy
- https://blog.logrocket.com/using-edge-functions-supabase-complete-guide/