# Database Development Log

Decizii despre SQLite, schema runtime, migrare, seed, backup/restore si sursele de adevar pentru date operationale.

## 2026-06-09 - SQLite Runtime Source of Truth

Observatie: editarile de hosts facute in aplicatia live puteau ramane in working tree-ul de pe jumper sau puteau fi suprascrise/confuzionate la push-ul de cod. Modelul vechi descria simultan `config/hosts.yaml` ca registry editabil in git si ca data operationala runtime, ceea ce nu era o sursa de adevar clara.

Decizie:

- `var/host-manager.sqlite` devine sursa de adevar runtime pentru registry si Work Orders
- `config/hosts.yaml` si `config/work-orders.yaml` raman seed/snapshot/export compatibility files
- la prima pornire, aplicatia seed-uieste documentele lipsa din YAML in SQLite
- download-urile `/download/hosts.yaml`, `/download/local-hosts.tsv` si `/download/monitoring.json` sunt randate din SQLite
- `config/local-hosts.tsv` ramane manifest generat explicit pentru sync-ul DNS local
- push-urile de cod catre jumper nu trebuie sa inlocuiasca baza runtime din `var/`

Scop:

- editarile facute in UI sa nu se piarda la deploy/push de cod
- sa existe o singura autoritate runtime
- YAML/TSV sa ramana utile pentru export, review si bootstrap fara sa fie storage-ul live

## 2026-06-09 - Relational Runtime Schema

Observatie: primul pas SQLite mutase sursa de adevar din git in baza de date, dar o pastra ca document YAML intr-o tabela generica. Asta rezolva pierderea editarilor la push, dar nu oferea o baza de date operationala reala.

Decizie:

- `hosts.fqdn` devine cheia reala pentru hosturi, ca numele complete sa evite coliziuni intre domenii
- `legacy_id` ramane doar compatibilitate pentru UI/API-ul curent
- aliasurile sunt pastrate in `host_aliases`, inclusiv dupa retragere
- vhosturile sunt in `vhosts` si pot fi mutate prin schimbarea `host_fqdn`
- rolurile, sursele, flagurile si SSH sunt in tabele separate, nu coloane adaugate continuu in `hosts`
- workerii de date au `data_workers`, `dhcp_leases` si `mdns_observations`
- certificatele emise au `certificates` si `certificate_dns_names`
- `documents` ramane doar tabel legacy pentru migrare din modelul vechi document-store

Scop:

- schema sa poata sustine inventar, DNS, vhosturi, observatii externe si certificate fara sa piarda istoric operational
- aliasurile/vhosturile retrase sa ramana audibile in baza de date
- structura sa fie extensibila fara sa supraincarce tabelul `hosts`