Ricostruire un database con restore
Traduzione automatica provvisoria, non revisionata. In caso di dubbio, consultare la versione inglese, che fa fede.
kent restore ricostruisce un database a partire da un archivio
.kent. È l'inverso di archive, e insieme
i due formano un percorso di andata e ritorno: un database che archiviate oggi è un database
che potete riavere.
Sintassi
kent restore --in <archive> --out <dbfilename>
Argomenti
| Opzione | Obbligatoria | Descrizione |
|---|---|---|
--in <archive> | Sì | L'archivio
.kent da leggere. |
--out <dbfilename> | Sì | Il database da creare. Rifiutato se esiste già. |
Gli stessi due nomi di opzione usati da archive, con i tipi di file
scambiati: qui --in è l'archivio, --out il database.
$ kent restore --in mydata.kent --out restored.sqlite
Restored restored.sqlite from mydata.kent
Tables: 11
Rows: 63686
Schema version: 2
Non sovrascriverà un database
Un --out esistente viene rifiutato, mai sostituito: la stessa regola che
segue createdb. Sono i due soli comandi di Kent che
scrivono un database, e la destinazione è l'unica cosa che non potete riavere se è
sbagliata.
$ kent restore --in mydata.kent --out existing.sqlite
kent restore: existing.sqlite already exists
Non c'è nemmeno modo di caricare un archivio dentro un database che contiene già dati. Sarebbe una fusione, un comando a parte che Kent non ha: si veda la Roadmap del prodotto.
Cosa torna indietro
Ogni valore, e la sua classe di memorizzazione SQLite. Un numero memorizzato come decimale torna decimale anziché intero, un dato binario vuoto torna come dato binario vuoto anziché come niente del tutto, e il testo conserva quello che conteneva: caratteri accentati, simboli, perfino interruzioni di riga incorporate.
È una promessa più forte di «gli stessi valori», ed è verificata come tale: il test di andata e ritorno confronta la classe di memorizzazione di ogni colonna di ogni riga, non solo come i valori si stampano.
L'unica cosa che non può tornare
Non-un-numero e infinito sono stati scritti nell'archivio come 0.0, perché
JSON non ha modo di esprimerli. Un ripristino non può distinguerli da uno zero misurato e non
finge di poterlo fare.
Un archivio vecchio si ripristina in un database vecchio
L'archivio registra la versione di schema del database da cui proviene, e
restore la rimette al suo posto. Quindi ripristinare l'archivio di un database
creato da una Cordelia più vecchia vi dà un database che quella Cordelia più vecchia
riconoscerebbe, e che la Cordelia attuale rifiuterà di aprire, esattamente come avrebbe
rifiutato l'originale.
kent restore non è uno strumento di migrazione, e nemmeno nient'altro in
Kent. Portare un database vecchio a uno schema attuale significa modificare i dati nel mezzo,
ed è a questo che serve la forma con pipe di
kent sqldump.
Archivi che rifiuta
Tutto viene controllato prima che il database venga creato, quindi un archivio difettoso non vi costa nulla: nessun file scritto a metà da notare ed eliminare.
| Rifiuto | Perché |
|---|---|
| Non è affatto un archivio | Non è uno zip, oppure non ha al suo interno né manifesto né schema. |
Non porta un mimetype, o ne porta uno che indica un altro
formato | Stessa ragione: la voce mimetype è ciò che un
.kent dichiara di essere. Si veda Archiviare per
cosa contiene. |
| Scritto da un Kent più recente di questo | Kent non tirerà a indovinare su un formato successivo a sé. Il messaggio indica la versione trovata e quella compresa. |
| Una tabella elencata ma mancante | Il manifesto dell'archivio l'aveva promessa. Un ripristino che caricasse in silenzio parte di un archivio dichiarando successo sarebbe peggio di uno che rifiuta. |
| Contenuti in disaccordo con il manifesto | Un conteggio di righe o una versione di schema che non corrisponde a ciò che l'archivio dice di sé. L'archivio è danneggiato o è stato costruito male. |
$ kent restore --in future.kent --out out.sqlite
kent restore: this archive is format version 99, but this build of kent understands version 1 at most
$ echo $?
1
Un fallimento non lascia nulla dietro di sé: nessun database parziale e nessuna directory temporanea. Ogni tabella viene caricata all'interno di una singola transazione.