tai-sql pull

tai-sql pull [-p <provider>] [--db-schema <x>] [-s <fichero>] [--syntax v1|v2]
             [--exclude <tabla>] [--env-var <VAR>] [--stdout] [--force]

Escribe el fichero schemas/<nombre>.py que describe una base de datos que ya existe. Es la dirección contraria a push, y sirve para empezar a usar tai-sql sobre algo que ya está en producción sin transcribir las tablas a mano.

tai-sql pull                                 # variable MAIN_DATABASE_URL, schema del motor
tai-sql pull -p OTRA_URL --db-schema ventas  # de dónde leer
tai-sql pull -s facturacion                  # cómo llamar al fichero
tai-sql pull --exclude tabla_legacy          # tabla que NO se declara
tai-sql pull --stdout                        # imprímelo, no escribas nada
tai-sql pull --syntax v1                     # type hints desnudos en vez de col[...]
tai-sql pull --force                         # sobrescribe un schema que ya exista

Es determinista y no pregunta nada

Con los mismos argumentos produce siempre el mismo fichero, así que sirve igual en un terminal que en un script.

No sobrescribe un schema que ya exista: tendría docstrings, feed(), triggers y calculadas que la base de datos no contiene. Para eso está --force, o -s <otro nombre>.

El provider

-p acepta el nombre de una variable de entorno (lo normal) o una cadena de conexión completa. En el fichero se escribe siempre env('NOMBRE'), nunca la cadena: el schema se commitea.

Con --env-var eliges qué nombre de variable se escribe, si no quieres el que usaste para leer.

Lo que no puede reconstruir

La base de datos no los guarda, así que no salen:

No se recupera	Por qué
feed()	Son datos, no estructura
Triggers	Viven en el schema y en el cliente generado, no en el motor
Columnas calculadas	Una calculada es una columna física: aparece como una columna normal
Encoders de columnas vectoriales	La columna sale, el encoder no
Descripciones	Solo las que estén como COMMENT

Tampoco distingue str de text cuando el motor usa el mismo tipo para los dos.

Los avisos del final

Al terminar dice qué había en la base de datos que el schema no declara, en bloques que no significan lo mismo:

1. Lo que un push posterior eliminaría, porque la comparación lo mira y no lo encuentra declarado: una tabla excluida con --exclude, una columna de tipo desconocido, un DEFAULT que el DSL no sabe escribir.
2. Lo que un push posterior ignora, y sobrevive intacto.
3. Las columnas cuyo tipo el DSL no reproduce exacto —un VARCHAR(50) se declara str, que es VARCHAR sin límite—: esas no se borran, se alteran.

Antes de aplicar nada

tai-sql pull
# revisa el fichero a mano
tai-sql push --dry-run --verbose

El schema que sale de pull es un punto de partida, no un resultado final. Revísalo —sobre todo los tipos y los DEFAULT— antes del primer push sobre una base de datos que te importe.

Después del pull

A partir de ahí manda el fichero: el ciclo es el de siempre, y pull no se vuelve a ejecutar.