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

2026-06-10 - DHCP Lease Push Collector

Observatie: DHCP-ul de pe 192.168.2.1 este autoritatea pentru alocarea IP-urilor LAN, dar baza runtime avea doar tabela dhcp_leases, fara un colector operational.

Decizie:

• MikroTik impinge evenimentele de lease prin lease-script catre POST /api/collect/dhcp-leases
• endpoint-ul este protejat cu HOST_MANAGER_DHCP_PUSH_TOKEN, separat de sesiunea OTP pentru UI
• ingest-ul scrie doar in dhcp_leases si actualizeaza workerul dhcp-router
• observatiile DHCP raman material de audit/propunere si nu modifica automat host registry-ul sau manifestul DNS

Scop:

• sa colectam lease-uri fara credential SSH pentru router in aplicatie
• sa pastram DHCP ca sursa observata cu prioritate mare, dar fara side effect automat asupra DNS-ului local