Metadatos: SQLite y Postgres

Los almacenes

En Postgres

import pg from 'pg';
import { postgresMetadata } from '@rebofiles/server';

metadata: await postgresMetadata(new pg.Pool({ connectionString: process.env.DATABASE_URL })),

Acepta cualquier cosa con query(text, values) que responda { rows }: pg, el Pool de Neon, PGlite. Con un pool, cada cambio mantiene un bloqueo de la base de datos mientras lee y escribe, así que dos servidores nunca cambian el drive a la vez; sin él, dos carpetas creadas en el mismo momento podrían ser ambas “(2)”. { table: 'acme_files' } para una tabla con otro nombre.

Qué se guarda

• Las entradas, una fila cada una, como JSON.
• Los ajustes del drive y de cada persona, y las contraseñas de los enlaces tal como las hace scrypt.
• La actividad, una fila por línea, encontrada por la entrada y las carpetas de las que trata.
• El texto de cada archivo: la búsqueda de texto completo de SQLite, o un tsvector en Postgres.
• Una revisión que sube con cada cambio, para que cada proceso sepa cuándo volver a leer el drive.

Un almacén propio

MetadataStore es load() y save(changes); revision, lock, los ajustes, record/activity y keepText/findText son opcionales, y sin ellos el servidor guarda eso en el proceso. Esquema de la base de datos tiene todas las tablas.

Por partes

SQLite, Postgres y el store en memoria responden lo que cada petición necesita, y nada más: una entrada y las carpetas sobre ella, lo que hay en una carpeta, lo que hay bajo otra, una búsqueda por nombre, la papelera, lo compartido con alguien. El drive nunca se carga entero, y un cambio escribe solo lo que tocó. Lo que cambió otro proceso se lee de la actividad que guardan.

Las columnas y tablas por las que se pregunta se añaden a una base hecha antes de ellas la primera vez que se abre, y las filas se rellenan una vez. Un store propio hace lo mismo con scoped; sin él, se guarda entero en memoria, como antes.