Salta ai contenuti
Rebase LogoRebase

Comandi del database

Panoramica

Sezione intitolata “Panoramica”

rebase db è la famiglia di comandi che raggiungono il database del progetto. Ognuno lavora sul database che il progetto risolve, nell’ordine elencato da Database Branching: --database-url, poi DATABASE_URL nella shell, il branch su cui è posizionato il checkout, DATABASE_URL in .env, --docker e, altrimenti, il database di sviluppo gestito che avvia rebase dev. rebase db url stampa quale sia.

push, generate e migrate sono descritti in dettaglio in Generazione dello schema, e ogni altro comando è nel riferimento CLI.

Comandi

Sezione intitolata “Comandi”

rebase db push

Sezione intitolata “rebase db push”

Invia le modifiche allo schema direttamente al database (solo per sviluppo):

rebase db push

--database-url <url> indica il database, e --docker quello di compose, avviato se necessario. Li accettano entrambi anche generate, migrate, branch, backup e restore.

Lascia stare ciò che le tue collezioni non descrivono: altre tabelle e viste, gli indici che hai scritto e i vincoli CHECK ed EXCLUDE sulla tabella di una collezione, che una collezione non può dichiarare. Vedi rebase db push per ciò che applica e prima di cosa si ferma.

rebase db generate

Sezione intitolata “rebase db generate”

Genera file di migrazione SQL a partire dalle modifiche allo schema:

rebase db generate

Crea file di migrazione con timestamp in drizzle/migrations/ che possono essere revisionati e committati.

rebase db migrate

Sezione intitolata “rebase db migrate”

Esegue le migrazioni del database in sospeso:

rebase db migrate

Applica tutte le migrazioni non ancora applicate al database.

Su un database su cui un server si è già avviato, la prima migrazione crea tabelle che l’avvio ha già creato, quindi lì il primo db migrate si ferma su already exists. Registra invece quella migrazione come applicata, una sola volta:

rebase db migrate --baseline <version>

La versione è il prefisso numerico del file di migrazione; db generate stampa il comando con la versione già inserita. Ogni db migrate successivo è un comando ordinario. Vedi --baseline per un database che registra già le migrazioni.

rebase db backup / backups / restore

Sezione intitolata “rebase db backup / backups / restore”
rebase db backup --out ./backups        # or s3://bucket/prefix, gs://bucket/prefix
rebase db backups list                  # list what is stored
rebase db restore ./backups/<file>.dump --yes

backup esegue pg_dump; restore esegue pg_restore e, essendo distruttivo, chiede di digitare yes su un terminale, oppure accetta --yes; senza un terminale e senza --yes si rifiuta e dice di passarlo. Da 0.25 In un database che contiene già ciò che il backup crea, restore richiede --clean. Senza di esso, si rifiuta prima di applicare qualsiasi cosa, ruoli del cluster compresi, e nomina gli oggetti d’intralcio e i due modi per aggirarli: --clean, oppure --create-db --target-db <new name>. Su 0.24 applicava i ruoli e poi falliva con l’errore di pg_restore schema "rebase" already exists. Da 0.25 restore rifiuta il database di sviluppo gestito: un backup porta le sue righe come dati COPY, che quel database non può ricevere, e su 0.24 il ripristino lo lasciava bloccato finché non veniva arrestato. Ripristina in Postgres in Docker (rebase db restore <dump> --docker --clean --yes), poi rebase db pull --from "$(rebase db url --docker)" --yes lo copia nel database gestito. Da 0.25 I percorsi relativi, e il valore predefinito ./backups, si risolvono rispetto alla directory da cui esegui rebase, così le tre righe qui sopra si incontrano in un’unica directory; un’opzione che un comando non accetta viene rifiutata prima che venga eseguito qualcosa. Su 0.24 il valore predefinito è backend/backups, quindi elencalo con --out ./backups. Da 0.25 Il dump e il suo file dei ruoli sono leggibili solo da te (0600), e contro un database non in esecuzione backup e restore stampano il banner che stampa db push. Su 0.24 i dump sono 0644. La pianificazione, il file dei ruoli che viaggia con ogni dump e la procedura di ripristino sono in Backup e ripristino.

rebase db pull

Sezione intitolata “rebase db pull”

Copia un altro database in quello di sviluppo locale:

rebase db pull --from postgres://…  [--anonymize]

--anonymize sostituisce i campi personali durante l’importazione, consentendo di lavorare localmente su una copia della produzione senza trasferire dati reali dei clienti su un laptop. Associa le colonne per nome ed è best-effort. Da 0.25 Una colonna sotto un indice univoco riceve un valore distinto per ogni riga, e il passaggio è un’unica transazione: se fallisce, le tabelle che avrebbe riscritto vengono svuotate e nominate, e il comando termina con 1. Su 0.24 falliva su token_hash una volta che gli utenti avevano effettuato l’accesso due volte, lasciando dati reali.

Dato che pg_dump rimuove i privilegi, la copia arriverebbe con i criteri RLS di origine ma senza le relative autorizzazioni sottostanti — causando il fallimento di ogni lettura come rebase_user con l’errore permission denied. L’operazione di pull ripristina successivamente il ruolo dell’applicazione, impiegando la medesima procedura usata all’avvio e da rebase db push, garantendo che le tabelle interne di Rebase rimangano protette come previsto.

La destinazione è sempre il database di sviluppo locale di questo progetto e non può essere modificata: il passaggio di --database-url viene rifiutato, evitando qualsiasi possibilità di eseguire un “pull verso la produzione”. --from è l’unica direzione consentita.

Da 0.25 Un pull sostituisce il contenuto del database locale: svuota prima ogni schema che copia, quindi una tabella che esiste solo in locale non sopravvive. Nel database di sviluppo gestito le righe viaggiano come istruzioni INSERT, che quel database accetta laddove COPY lo bloccherebbe. Su 0.24 un pull nel database gestito falliva alla prima tabella e lo lasciava senza rispondere finché non veniva terminato.

rebase db url

Sezione intitolata “rebase db url”

Stampa la stringa di connessione utilizzata dal progetto, e nient’altro, facilitando l’uso in pipe:

rebase db url
psql "$(rebase db url)"

Il database di sviluppo gestito è il caso principale che necessita di questo comando: .env lascia intenzionalmente DATABASE_URL commentato, e la porta è calcolata dal percorso del progetto, per cui nessun elemento su disco la definisce in modo esplicito. Da 0.25 Mantiene quella porta tra un arresto e un avvio, a meno che qualcos’altro non l’abbia occupata; su 0.24 ogni avvio ne sceglieva una nuova. Quando imposti un tuo DATABASE_URL, viene stampato quello — l’ordine di risoluzione è lo stesso seguito da qualsiasi altro comando. Il comando avvia il database gestito qualora non sia già in esecuzione.

Da 0.25 Dopo rebase dev --docker, db url e gli altri comandi usano quel database Docker (e lo dicono su stderr) finché non viene eseguito un rebase dev senza il flag. La scelta è conservata in .rebase/dev-database.json e ha la precedenza dove l’ha --docker, sotto ogni stringa di connessione. Un --docker che digiti e che una stringa di connessione supera non avvia alcun container: una riga su stderr dice che è stato ignorato, nomina ciò che ha vinto e dice come raggiungere invece Docker. Un rebase dev --docker superato in questo modo mantiene la scelta memorizzata così com’era, quindi, una volta tolta la stringa di connessione, i comandi seguono di nuovo Docker. Su 0.24 ogni comando richiede il proprio --docker, e uno superato avvia comunque il container.

Da 0.25 rebase init assegna a ogni progetto la propria porta compose, tra 5433 e 5632 in base al percorso del progetto, e --docker controlla che ciò che risponde su di essa sia il container db di questo progetto. Quando la porta è occupata da un altro container o da un Postgres esterno a Docker, si ferma e lo nomina invece di accedere al database di qualcun altro. Per spostare il progetto, cambia la porta host del servizio db in docker-compose.yml, e DATABASE_URL se .env ne imposta uno. Su 0.24 ogni scaffold prendeva la prima porta libera a partire da 5432, quindi progetti creati uno accanto all’altro potevano condividerne una.

rebase db stop / rebase db reset

Sezione intitolata “rebase db stop / rebase db reset”

Valido solo per il database di sviluppo gestito:

rebase db stop     # stop it; the data is kept
rebase db reset    # delete it and start over

Appartiene al progetto, non al comando che l’ha avviato, quindi arrestare rebase dev lo lascia in esecuzione per gli altri comandi. Dopo 30 minuti senza nulla di connesso si arresta da solo, e il comando successivo che ne ha bisogno lo avvia di nuovo. Da 0.25 rebase dev lo dice mentre si arresta, indicando come arrestare subito il database; su 0.24 non diceva nulla.

Da 0.25 db stop con un rebase dev in esecuzione dice che il suo backend non può raggiungere il database finché non torna disponibile. Il comando successivo che ne ha bisogno, per esempio rebase db url, lo avvia sulla stessa porta, e il backend si riconnette senza riavvio. Su 0.24 tornava su un’altra porta, e il backend rispondeva 503 finché rebase dev non veniva riavviato.

rebase db branch

Sezione intitolata “rebase db branch”
rebase db branch create <name>
rebase db branch list
rebase db branch info <name>
rebase db branch switch <name>     # work on it; every later command follows
rebase db branch switch            # say which branch you are on
rebase db branch switch --off      # back to the main database
rebase db branch delete <name>
rebase db branch prune [--older-than 14d] [--include-dev-diff]

PostgreSQL non consente di copiare o eliminare un database a cui è connesso qualsiasi altro processo, e il caso più tipico di “qualsiasi altro processo” è la tua istanza di rebase dev. create e delete indicano cosa sta occupando il database; --force disconnette preventivamente tali sessioni.

Ogni branch è una copia completa su disco, pertanto richiede una pulizia periodica. prune rimuove tre elementi: una voce il cui database è stato rimosso all’esterno di Rebase, un database di branch la cui voce non è mai stata salvata e — solo specificando --older-than — i branch più vecchi dell’età specificata. Salvo l’uso di --yes, richiede conferma prima di eliminare qualsiasi cosa. Da 0.25 Senza un terminale su cui chiedere, come in CI, non rimuove nulla, dice di passare --yes e termina con 1; su 0.24 dice “Nothing was changed.” e termina con 0. list e info si limitano a leggere: un database su cui non è stato creato alcun branch non ne ha, e non vi creano lo schema rebase. Su 0.24 creano il registro.

switch registra il branch in .rebase/branch.json e non modifica mai .env. Ha la precedenza su DATABASE_URL presente in .env ma cede il passo a --database-url o a una variabile DATABASE_URL definita nella shell; pertanto, un flag passato da riga di comando ha sempre priorità rispetto a uno switch effettuato precedentemente. delete rifiuta il branch su cui ti trovi, poiché ogni comando del checkout, delete compreso, punta a esso: prima switch --off, poi eliminalo. L’intero flusso di lavoro è in Database Branching.

Risorse correlate

Sezione intitolata “Risorse correlate”