27 lines
1.7 KiB
Markdown
27 lines
1.7 KiB
Markdown
# 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.yaml` come 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.
|