1.5 KiB
Binding di database specifiche dell'installazione
Il Metadata Catalog separa il Workspace Database logico dalla Database Binding che lo rende
raggiungibile in una specifica installazione. Esiste un solo Workspace Database per workspace_id
e una sola binding attiva nel catalogo di ciascuna installazione; per esempio PSD usa REST in locale
e PostgreSQL diretto sul server senza diventare due database distinti.
Nel modello finale il catalogo è autorevole per engine, nome fisico, schema, capability e binding,
mentre thoth-workspaces.yaml conserva l'identità del workspace. Gli attuali campi DWH dei
descriptor sono una sorgente di bootstrap da importare e confrontare durante un cutover esplicito,
non una seconda fonte di verità permanente.
Considered Options
- Conservare un record database per ogni trasporto avrebbe duplicato identità, struttura e metadati dello stesso DWH fra locale e server.
- Conservare permanentemente i dati DWH sia nello YAML sia nel catalogo avrebbe introdotto conflitti non risolvibili deterministicamente.
- Rendere globali le binding avrebbe mescolato endpoint e credenziali che appartengono a installazioni con topologie e confini di sicurezza differenti.
Consequences
La lista amministrativa unisce workspace YAML, database configurati e record orphaned. Il cutover deve importare e confrontare la configurazione esistente prima di rimuoverla dai descriptor; il runtime non deve osservare simultaneamente due autorità discordanti.