1.7 KiB
PostgreSQL come autorità dei metadati dei database dei workspace
ThothII userà un Metadata Catalog PostgreSQL interno per conservare, per ogni workspace, la
struttura fisica acquisita interrogando il relativo database e i metadati semantici generati con
l'AI. Ogni Workspace Database conserverà un workspace_id obbligatorio e univoco: questo realizza
l'associazione uno-a-uno senza introdurre nel catalogo una tabella Workspace o una foreign key SQL.
Identità e lista dei workspace resteranno autorevoli in thoth-workspaces.yaml; il servizio
validerà il riferimento contro quel catalogo. schema/annotations.yaml verrà sostituito come input
del core in uno step successivo; l'interfaccia e il lifecycle amministrativi resteranno separati dal
workflow NL→SQL.
Considered Options
- Conservare
annotations.yamlcome fonte di verità avrebbe mantenuto il revisionamento Git, ma non avrebbe fornito il CRUD e il processo di introspezione/generazione richiesti. - Leggere metadati mutabili dal catalogo senza un confine esplicito avrebbe accoppiato il workflow alla disponibilità del nuovo servizio e consentito viste parziali durante gli aggiornamenti.
Consequences
PSD importerà le annotations esistenti; gli altri workspace genereranno i metadati da zero. Il
cutover futuro dovrà sostituire consapevolmente i consumatori delle annotations e verificarne
l'equivalenza semantica. PostgreSQL può garantire che uno stesso workspace_id non sia assegnato a
due database, ma l'esistenza del workspace e la gestione di rename o rimozioni restano responsabilità
del confine applicativo con il catalogo YAML. Le sessioni di test esistenti non sono un vincolo di
migrazione.