Loading documentation...
Preparing Ring content
Konzepte, Nutzen und typische Clone-Szenarien — weniger Code.
Konzepte, Nutzen und typische Clone-Szenarien — weniger Code.
Preparing Ring content
Preparing Ring content
Preparing Ring content
Ring hält sein PostgreSQL-Schema an zwei Stellen in ring/web/data/. schema.sql ist die zusammengeführte einzige Referenz für neue Datenbanken. migrations/ enthält die nummerierten inkrementellen Dateien, die bestehende Datenbanken auf denselben Stand gebracht haben. Diese Seite erklärt, was du wann verwendest.
Nutze die Tabs Gründer / Entwickler in der Seitenleiste, um diese Seite zu filtern. Gemeinsame Abschnitte gelten für beide Zielgruppen.
Status: ./install.sh setup-db und npm run db:apply-schema schlagen in öffentlichen Checkouts derzeit fehl, weil sie Pfade suchen, die nach web/ verschoben wurden. Außerdem enthält schema.sql die Zeile CREATE EXTENSION IF NOT EXISTS postgis;, sodass ein einfaches psql -f data/schema.sql auf PostgreSQL-Images ohne PostGIS (zum Beispiel postgres:16-alpine) mit einem Fehler abbricht. Nutze die Befehle aus Schritt 2 unten.
| Frühere Dokumentation sagte | Aktuelles Verhalten |
|---|---|
schema.sql anwenden, danach 002, 003, 004 der Reihe nach | Frische Installationen wenden nur web/data/schema.sql an (zusammengeführt, Version 4.1.0) |
./scripts/run-migration.sh oder apply-*-migrations-dev.sh ausführen | Diese Hilfsskripte sind nicht im öffentlichen Baum. Nutze psql direkt |
Homebrew postgresql@18 mit einem Bootstrap-Skript installieren | Jedes PostgreSQL ab 16 funktioniert. Das Bootstrap-Skript ist Ringdom-intern |
News aus scripts/seed-news-v1.6.0.sql laden | Diese Datei existiert nicht. Startdaten für Währungen, Länder, Shop-Einstellungen und News-Kategorien stehen in schema.sql |
data/schema-delta.sql | Wird nicht verwendet. Änderungen liegen als nummerierte Dateien in data/migrations/ |
Du musst kein SQL verstehen, um einen Ring-Klon zu betreiben. Die Regel, der dein Entwickler folgt, solltest du aber kennen: Eine neue Datenbank bekommt eine Datei, eine bestehende Datenbank bekommt nur die neuen Dateien. Diese Regel sorgt dafür, dass Upgrades langweilig bleiben.
Eine einzige Schema-Datei legt alle Tabellen an (109 in Version 4.1.0) und dazu die Referenzdaten. Kein Nachspielen der Historie.
Dein Entwickler wendet nach einem Backup nur die nummerierten Dateien an, die deine Datenbank noch nicht kennt.
PostgreSQL ist das Standard-Backend für die Produktion (k8s-postgres-fcm).
Nächster Schritt: die App gegen die gerade angelegte Datenbank starten.
Gleicher Ablauf: das Schema auf den Postgres-Container aus Compose anwenden.
Voraussetzung: warum k8s-postgres-fcm dieses Schema braucht.
Siehe auch: install.sh und die npm-Skripte für die Datenbank, einschließlich derer, die heute fehlschlagen.
Ring hält sein PostgreSQL-Schema an zwei Stellen in ring/web/data/. schema.sql ist die zusammengeführte einzige Referenz für neue Datenbanken. migrations/ enthält die nummerierten inkrementellen Dateien, die bestehende Datenbanken auf denselben Stand gebracht haben. Diese Seite erklärt, was du wann verwendest.
Nutze die Tabs Gründer / Entwickler in der Seitenleiste, um diese Seite zu filtern. Gemeinsame Abschnitte gelten für beide Zielgruppen.
Status: ./install.sh setup-db und npm run db:apply-schema schlagen in öffentlichen Checkouts derzeit fehl, weil sie Pfade suchen, die nach web/ verschoben wurden. Außerdem enthält schema.sql die Zeile CREATE EXTENSION IF NOT EXISTS postgis;, sodass ein einfaches psql -f data/schema.sql auf PostgreSQL-Images ohne PostGIS (zum Beispiel postgres:16-alpine) mit einem Fehler abbricht. Nutze die Befehle aus Schritt 2 unten.
| Frühere Dokumentation sagte | Aktuelles Verhalten |
|---|---|
schema.sql anwenden, danach 002, 003, 004 der Reihe nach | Frische Installationen wenden nur web/data/schema.sql an (zusammengeführt, Version 4.1.0) |
./scripts/run-migration.sh oder apply-*-migrations-dev.sh ausführen | Diese Hilfsskripte sind nicht im öffentlichen Baum. Nutze psql direkt |
Homebrew postgresql@18 mit einem Bootstrap-Skript installieren | Jedes PostgreSQL ab 16 funktioniert. Das Bootstrap-Skript ist Ringdom-intern |
News aus scripts/seed-news-v1.6.0.sql laden | Diese Datei existiert nicht. Startdaten für Währungen, Länder, Shop-Einstellungen und News-Kategorien stehen in schema.sql |
data/schema-delta.sql | Wird nicht verwendet. Änderungen liegen als nummerierte Dateien in data/migrations/ |
Du musst kein SQL verstehen, um einen Ring-Klon zu betreiben. Die Regel, der dein Entwickler folgt, solltest du aber kennen: Eine neue Datenbank bekommt eine Datei, eine bestehende Datenbank bekommt nur die neuen Dateien. Diese Regel sorgt dafür, dass Upgrades langweilig bleiben.
Eine einzige Schema-Datei legt alle Tabellen an (109 in Version 4.1.0) und dazu die Referenzdaten. Kein Nachspielen der Historie.
Dein Entwickler wendet nach einem Backup nur die nummerierten Dateien an, die deine Datenbank noch nicht kennt.
PostgreSQL ist das Standard-Backend für die Produktion (k8s-postgres-fcm).
Nächster Schritt: die App gegen die gerade angelegte Datenbank starten.
Gleicher Ablauf: das Schema auf den Postgres-Container aus Compose anwenden.
Voraussetzung: warum k8s-postgres-fcm dieses Schema braucht.
Siehe auch: install.sh und die npm-Skripte für die Datenbank, einschließlich derer, die heute fehlschlagen.
Ring hält sein PostgreSQL-Schema an zwei Stellen in ring/web/data/. schema.sql ist die zusammengeführte einzige Referenz für neue Datenbanken. migrations/ enthält die nummerierten inkrementellen Dateien, die bestehende Datenbanken auf denselben Stand gebracht haben. Diese Seite erklärt, was du wann verwendest.
Nutze die Tabs Gründer / Entwickler in der Seitenleiste, um diese Seite zu filtern. Gemeinsame Abschnitte gelten für beide Zielgruppen.
Status: ./install.sh setup-db und npm run db:apply-schema schlagen in öffentlichen Checkouts derzeit fehl, weil sie Pfade suchen, die nach web/ verschoben wurden. Außerdem enthält schema.sql die Zeile CREATE EXTENSION IF NOT EXISTS postgis;, sodass ein einfaches psql -f data/schema.sql auf PostgreSQL-Images ohne PostGIS (zum Beispiel postgres:16-alpine) mit einem Fehler abbricht. Nutze die Befehle aus Schritt 2 unten.
| Frühere Dokumentation sagte | Aktuelles Verhalten |
|---|---|
schema.sql anwenden, danach 002, 003, 004 der Reihe nach | Frische Installationen wenden nur web/data/schema.sql an (zusammengeführt, Version 4.1.0) |
./scripts/run-migration.sh oder apply-*-migrations-dev.sh ausführen | Diese Hilfsskripte sind nicht im öffentlichen Baum. Nutze psql direkt |
Homebrew postgresql@18 mit einem Bootstrap-Skript installieren | Jedes PostgreSQL ab 16 funktioniert. Das Bootstrap-Skript ist Ringdom-intern |
News aus scripts/seed-news-v1.6.0.sql laden | Diese Datei existiert nicht. Startdaten für Währungen, Länder, Shop-Einstellungen und News-Kategorien stehen in schema.sql |
data/schema-delta.sql | Wird nicht verwendet. Änderungen liegen als nummerierte Dateien in data/migrations/ |
Du musst kein SQL verstehen, um einen Ring-Klon zu betreiben. Die Regel, der dein Entwickler folgt, solltest du aber kennen: Eine neue Datenbank bekommt eine Datei, eine bestehende Datenbank bekommt nur die neuen Dateien. Diese Regel sorgt dafür, dass Upgrades langweilig bleiben.
Eine einzige Schema-Datei legt alle Tabellen an (109 in Version 4.1.0) und dazu die Referenzdaten. Kein Nachspielen der Historie.
Dein Entwickler wendet nach einem Backup nur die nummerierten Dateien an, die deine Datenbank noch nicht kennt.
PostgreSQL ist das Standard-Backend für die Produktion (k8s-postgres-fcm).
Nächster Schritt: die App gegen die gerade angelegte Datenbank starten.
Gleicher Ablauf: das Schema auf den Postgres-Container aus Compose anwenden.
Voraussetzung: warum k8s-postgres-fcm dieses Schema braucht.
Siehe auch: install.sh und die npm-Skripte für die Datenbank, einschließlich derer, die heute fehlschlagen.
schema.sql an. Die Seite ist bereit für die erste Anmeldung des Admins.051_likes_uci_favorites_indexes.sql. Dein Entwickler macht ein Backup, wendet genau diese Datei an und deployt neu.051 können eine passende .down.sql-Datei mitbringen, damit sich die Änderung zurücknehmen lässt. Ältere Dateien haben keine.Die App verbindet sich über DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD und DB_SSL. DATABASE_URL liest sie nicht. Siehe Umgebung.
Führe den nächsten Schritt als Superuser oder als Eigentümer der Datenbank aus, weil schema.sql Erweiterungen anlegt.
Wenn auf deinem Server PostGIS installiert ist (zum Beispiel ein Image postgis/postgis), wende die Datei unverändert an:
Auf PostgreSQL ohne PostGIS entfernst du zuerst die PostGIS-Zeile. Keine Tabelle nutzt einen PostGIS-Typ, deshalb ändert sich sonst nichts:
Gib der Rolle deiner App (DB_USER) Zugriff auf das Schema public und starte dann die App.
Wende nur die Dateien an, die deine Datenbank noch nicht kennt. Einige Migrationen tragen sich mit einem INSERT ... WHERE NOT EXISTS in schema_versions ein (016 bis 025, 037, 043 bis 046, 050, 051). Die anderen nicht. Prüfe deshalb vor dem Anwenden, ob die Tabellen oder Indizes, die sie anlegen, schon existieren.
Um eine Migration mit Down-Datei zurückzunehmen, wende 051_likes_uci_favorites_indexes.down.sql auf dieselbe Weise an. Sie löscht auch ihre Zeile in schema_versions.
Nimm die nächste freie Nummer nach der höchsten Datei in data/migrations/. Mache sie idempotent (IF NOT EXISTS), trage sie in schema_versions ein und füge eine .down.sql hinzu, wenn die Änderung umkehrbar ist.
Das führt ring/scripts/flatten-schema-from-migrations.sh aus. Es braucht ein lokales PostgreSQL, in dem deine Rolle Datenbanken anlegen darf (PGHOST und PGUSER sind standardmäßig localhost und ring_user). Das Skript legt die temporäre Datenbank ring_schema_flatten neu an, sichert schema.sql als schema.sql.bak-pre-flatten-<timestamp>, wendet das bisherige Schema und alle Migrationen außer 001 an, exportiert DDL und Referenzdaten und prüft das Ergebnis auf ring_schema_flatten_verify. Der Prüfschritt braucht PostGIS, aus dem oben genannten Grund.
Nein. Das Zusammenführen schreibt nur die Datei schema.sql im Repository neu. Laufende Datenbanken berührt es nie.
schema.sql erstellt. Welche Dateien brauche ich?Vergleiche SELECT version FROM schema_versions mit den nummerierten Dateien und wende die fehlenden nach einem Backup der Reihe nach an. Nur manche Dateien tragen eine Version ein (siehe Bestehende Datenbank oben). Prüfe im Zweifel also ihre Tabellen. Beachte, dass eine frische Installation aus dem heutigen schema.sql Versionen bis 045 anzeigt, obwohl die Tabellen und Indizes aus 046 bis 051 bereits vorhanden sind.
CREATE EXTENSION postgis fehl?Dein PostgreSQL-Build enthält kein PostGIS. Entferne die Zeile wie in Schritt 2 gezeigt oder nutze ein Image mit PostGIS.
schema.sql an. Die Seite ist bereit für die erste Anmeldung des Admins.051_likes_uci_favorites_indexes.sql. Dein Entwickler macht ein Backup, wendet genau diese Datei an und deployt neu.051 können eine passende .down.sql-Datei mitbringen, damit sich die Änderung zurücknehmen lässt. Ältere Dateien haben keine.Die App verbindet sich über DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD und DB_SSL. DATABASE_URL liest sie nicht. Siehe Umgebung.
Führe den nächsten Schritt als Superuser oder als Eigentümer der Datenbank aus, weil schema.sql Erweiterungen anlegt.
Wenn auf deinem Server PostGIS installiert ist (zum Beispiel ein Image postgis/postgis), wende die Datei unverändert an:
Auf PostgreSQL ohne PostGIS entfernst du zuerst die PostGIS-Zeile. Keine Tabelle nutzt einen PostGIS-Typ, deshalb ändert sich sonst nichts:
Gib der Rolle deiner App (DB_USER) Zugriff auf das Schema public und starte dann die App.
Wende nur die Dateien an, die deine Datenbank noch nicht kennt. Einige Migrationen tragen sich mit einem INSERT ... WHERE NOT EXISTS in schema_versions ein (016 bis 025, 037, 043 bis 046, 050, 051). Die anderen nicht. Prüfe deshalb vor dem Anwenden, ob die Tabellen oder Indizes, die sie anlegen, schon existieren.
Um eine Migration mit Down-Datei zurückzunehmen, wende 051_likes_uci_favorites_indexes.down.sql auf dieselbe Weise an. Sie löscht auch ihre Zeile in schema_versions.
Nimm die nächste freie Nummer nach der höchsten Datei in data/migrations/. Mache sie idempotent (IF NOT EXISTS), trage sie in schema_versions ein und füge eine .down.sql hinzu, wenn die Änderung umkehrbar ist.
Das führt ring/scripts/flatten-schema-from-migrations.sh aus. Es braucht ein lokales PostgreSQL, in dem deine Rolle Datenbanken anlegen darf (PGHOST und PGUSER sind standardmäßig localhost und ring_user). Das Skript legt die temporäre Datenbank ring_schema_flatten neu an, sichert schema.sql als schema.sql.bak-pre-flatten-<timestamp>, wendet das bisherige Schema und alle Migrationen außer 001 an, exportiert DDL und Referenzdaten und prüft das Ergebnis auf ring_schema_flatten_verify. Der Prüfschritt braucht PostGIS, aus dem oben genannten Grund.
Nein. Das Zusammenführen schreibt nur die Datei schema.sql im Repository neu. Laufende Datenbanken berührt es nie.
schema.sql erstellt. Welche Dateien brauche ich?Vergleiche SELECT version FROM schema_versions mit den nummerierten Dateien und wende die fehlenden nach einem Backup der Reihe nach an. Nur manche Dateien tragen eine Version ein (siehe Bestehende Datenbank oben). Prüfe im Zweifel also ihre Tabellen. Beachte, dass eine frische Installation aus dem heutigen schema.sql Versionen bis 045 anzeigt, obwohl die Tabellen und Indizes aus 046 bis 051 bereits vorhanden sind.
CREATE EXTENSION postgis fehl?Dein PostgreSQL-Build enthält kein PostGIS. Entferne die Zeile wie in Schritt 2 gezeigt oder nutze ein Image mit PostGIS.
schema.sql an. Die Seite ist bereit für die erste Anmeldung des Admins.051_likes_uci_favorites_indexes.sql. Dein Entwickler macht ein Backup, wendet genau diese Datei an und deployt neu.051 können eine passende .down.sql-Datei mitbringen, damit sich die Änderung zurücknehmen lässt. Ältere Dateien haben keine.Die App verbindet sich über DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD und DB_SSL. DATABASE_URL liest sie nicht. Siehe Umgebung.
Führe den nächsten Schritt als Superuser oder als Eigentümer der Datenbank aus, weil schema.sql Erweiterungen anlegt.
Wenn auf deinem Server PostGIS installiert ist (zum Beispiel ein Image postgis/postgis), wende die Datei unverändert an:
Auf PostgreSQL ohne PostGIS entfernst du zuerst die PostGIS-Zeile. Keine Tabelle nutzt einen PostGIS-Typ, deshalb ändert sich sonst nichts:
Gib der Rolle deiner App (DB_USER) Zugriff auf das Schema public und starte dann die App.
Wende nur die Dateien an, die deine Datenbank noch nicht kennt. Einige Migrationen tragen sich mit einem INSERT ... WHERE NOT EXISTS in schema_versions ein (016 bis 025, 037, 043 bis 046, 050, 051). Die anderen nicht. Prüfe deshalb vor dem Anwenden, ob die Tabellen oder Indizes, die sie anlegen, schon existieren.
Um eine Migration mit Down-Datei zurückzunehmen, wende 051_likes_uci_favorites_indexes.down.sql auf dieselbe Weise an. Sie löscht auch ihre Zeile in schema_versions.
Nimm die nächste freie Nummer nach der höchsten Datei in data/migrations/. Mache sie idempotent (IF NOT EXISTS), trage sie in schema_versions ein und füge eine .down.sql hinzu, wenn die Änderung umkehrbar ist.
Das führt ring/scripts/flatten-schema-from-migrations.sh aus. Es braucht ein lokales PostgreSQL, in dem deine Rolle Datenbanken anlegen darf (PGHOST und PGUSER sind standardmäßig localhost und ring_user). Das Skript legt die temporäre Datenbank ring_schema_flatten neu an, sichert schema.sql als schema.sql.bak-pre-flatten-<timestamp>, wendet das bisherige Schema und alle Migrationen außer 001 an, exportiert DDL und Referenzdaten und prüft das Ergebnis auf ring_schema_flatten_verify. Der Prüfschritt braucht PostGIS, aus dem oben genannten Grund.
Nein. Das Zusammenführen schreibt nur die Datei schema.sql im Repository neu. Laufende Datenbanken berührt es nie.
schema.sql erstellt. Welche Dateien brauche ich?Vergleiche SELECT version FROM schema_versions mit den nummerierten Dateien und wende die fehlenden nach einem Backup der Reihe nach an. Nur manche Dateien tragen eine Version ein (siehe Bestehende Datenbank oben). Prüfe im Zweifel also ihre Tabellen. Beachte, dass eine frische Installation aus dem heutigen schema.sql Versionen bis 045 anzeigt, obwohl die Tabellen und Indizes aus 046 bis 051 bereits vorhanden sind.
CREATE EXTENSION postgis fehl?Dein PostgreSQL-Build enthält kein PostGIS. Entferne die Zeile wie in Schritt 2 gezeigt oder nutze ein Image mit PostGIS.