27 lines
1.5 KiB
Markdown
27 lines
1.5 KiB
Markdown
# 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.
|