Exportar una base de datos con sqldump

Traducción automática provisional, sin revisar. En caso de duda, consulte la versión en inglés, que es la versión de referencia.

kent sqldump exporta una base de datos a un script .sql que la recrea al reproducirlo. Con --schema-only exporta solo la estructura, que es como se producen los archivos de esquema publicados en El esquema en SQL.

Es de solo lectura. kent sqldump abre la base de datos en el modo de solo lectura de SQLite y no escribe nada en ella.

Sinopsis

kent sqldump --in <dbfilename> [--out <outfile>] [--schema-only]

Argumentos

OpciónObligatoriaDescripción
--in <dbfilename>SíRuta de una base de datos .sqlite existente que exportar.
--out <outfile>NoDónde escribir el script. Omítala para escribir en la salida estándar.
--schema-onlyNoEmite el esquema y ningún dato de filas. No toma valor.

Escribir en un archivo o en la salida estándar

Con --out, el script se escribe en ese archivo. Sin ella, el script va a la salida estándar para poder canalizarlo hacia otra cosa:

$ kent sqldump --in old.sqlite | python3 migrate.py > new.sql

Como la salida estándar lleva el propio script, todos los mensajes que imprime kent sqldump van a la salida de error, errores y avisos por igual. Nada de lo que imprime Kent se intercala nunca en la exportación.

Qué contiene el script

En orden: una cabecera de comentario, PRAGMA foreign_keys=OFF y el PRAGMA user_version que restaura la marca de esquema, una transacción, todos los CREATE TABLE, todas las filas como INSERT, luego los índices, vistas y disparadores, y después COMMIT.

$ kent sqldump --in mydata.sqlite --out mydata.sql
$ head -10 mydata.sql
-- kent sqldump
-- source: mydata.sqlite
-- kent: 1.3.4
-- cordelia: 1.3.3
-- exported: 2026-09-16T22:55:58Z
-- user_version: 2

PRAGMA foreign_keys=OFF;
PRAGMA user_version = 2;
BEGIN TRANSACTION;

Los datos de las tablas van antes que los disparadores de forma deliberada. Un disparador que modifica otra tabla al insertar una fila se dispararía de otro modo una segunda vez durante la restauración, dejando la base restaurada sutilmente distinta de la original.

PRAGMA user_version se arrastra porque Cordelia se niega a abrir una base de datos cuya versión de esquema no reconozca. Sin él, una exportación restaurada informaría de la versión 0 y Cordelia no la abriría.

Por qué la cabecera registra la versión de Cordelia

Cordelia es quien define el esquema de una base de datos Cordelia; Kent solo lo transcribe. Una compilación posterior de Kent produce el mismo esquema a partir de la misma base de datos, así que la versión del propio Kent no identifica de dónde salió el esquema: la de Cordelia sí. Para un archivo de esquema conservado como artefacto de referencia, esa es la línea que importa.

Dos exportaciones de la misma base de datos coinciden

Salvo por la marca de tiempo de la cabecera, dos exportaciones de la misma base de datos son idénticas byte a byte. Las tablas se emiten por orden de nombre y las filas por orden de inserción, de modo que una exportación puede compararse con otra, que es de lo que se trata si está escribiendo un script para convertir un esquema antiguo en uno nuevo.

--schema-only

Emite todas las sentencias CREATE y el PRAGMA user_version, sin ningún INSERT. Para una base de datos recién creada eso es la diferencia entre 54 KiB y 2,3 MiB, ya que en torno al 98 % de las filas de una base nueva son datos de consulta precargados:

$ kent sqldump --in mydata.sqlite --schema-only --out schema_01.sql
$ grep -c '^CREATE' schema_01.sql
129
$ grep -c '^INSERT' schema_01.sql
0

El script se sigue reproduciendo: simplemente produce una base de datos vacía con el mismo esquema. Esta es la forma que hay que usar para un artefacto de referencia por versión, donde diff schema_01.sql schema_02.sql pretende leerse como una declaración de lo que cambió entre dos versiones de esquema.

Una base de datos antigua se exporta, no se rechaza

A diferencia de todos los demás comandos de Kent, sqldump no rechaza una base de datos cuya versión de esquema difiera de la que espera esta compilación. La exporta de todos modos, con una nota en la salida de error. Rechazarla frustraría el propósito: exportar una base de datos antigua es exactamente lo que se hace antes de migrarla.

$ kent sqldump --in old.sqlite --out old.sql
kent sqldump: note: this database reports schema version 0, but this build of cordelia expects 2. Exporting it anyway.
$ echo $?
0

Compárese con kent info, que rechaza ese mismo archivo.

La exportación se escribe sobre nada

Que --in y --out nombren el mismo archivo se rechaza antes de leer nada, en lugar de truncar la base de datos que pidió exportar.

$ kent sqldump --in mydata.sqlite --out mydata.sqlite
kent sqldump: refusing to write the export over its own source: mydata.sqlite

Una ruta dada a --in que no existe se informa como ausente y no se crea: la propia llamada de apertura de SQLite crea el archivo que se le indica, así que una ruta mal escrita dejaría si no una base de datos vacía perdida por ahí.

$ kent sqldump --in nope.sqlite
kent sqldump: nope.sqlite does not exist

Esquemas que no se pueden exportar

Una base de datos Cordelia no usa ninguno de estos. kent sqldump los rechaza en lugar de producir un script que restauraría incorrectamente: una exportación errónea es peor que una rechazada.

CaracterísticaPor qué¿Rechazada con --schema-only?
Tablas virtualesCrear una arrastra tablas sombra que aparecen como tablas ordinarias: una tabla FTS5 produce cinco. Reproducir el CREATE VIRTUAL TABLE las recrea, así que el CREATE TABLE de cada sombra falla luego por existir ya.Sí
Tablas WITHOUT ROWIDLas filas no tienen rowid por el que ordenarlas, así que la exportación no podría hacerse determinista.No
Columnas generadasEn una columna generada no se puede insertar, así que el INSERT reproducido fallaría.No

Dos de los tres existen solo porque se están escribiendo filas, de modo que --schema-only los levanta: sin INSERT que falle y sin filas que ordenar, ninguno de los dos problemas se plantea. El rechazo de las tablas virtuales tiene que ver con el esquema en sí, así que se mantiene en ambos modos.

Restaurar una exportación

El script se reproduce con cualquier herramienta SQLite, no solo con Kent:

$ kent sqldump --in mydata.sqlite --out mydata.sql
$ sqlite3 restored.sqlite < mydata.sql
$ sqlite3 restored.sqlite 'PRAGMA user_version'
2
$ sqlite3 restored.sqlite 'SELECT count(*) FROM better_labels_lookup'
16866

Restaure en un archivo vacío, no en una base de datos que kent createdb ya haya creado. Una exportación lleva todos los CREATE TABLE, así que reproducirla sobre una base de datos Cordelia existente falla de inmediato con table AadAccelFeatures already exists. La exportación es autónoma: es el esquema y los datos.

Una exportación es la entrada de una migración, no una migración en sí. Convertir un esquema antiguo en uno nuevo significa editar el script entre el volcado y la restauración: para eso está la tubería de arriba. Un script de conversión no debe eliminar las tablas de referencia precargadas (FileTypeLookup, FieldTypeLookup, better_labels_definitions, better_labels_lookup, unas 19 700 filas). Nada las regenera durante una restauración, porque nada crea el esquema salvo el propio script; eliminar sus filas produce una base de datos con las tablas de consulta vacías.

Véase también Mensajes de error y códigos de salida y El esquema en SQL.

Véase también