TezzDB data model and operational flow
How the site currently stores app metadata, and the baseline conventions for extending the schema.
Current Table Contract
Table: tn_apps
Columns:
- id (INT, PK, AUTO_INCREMENT)
- name (VARCHAR 120, NOT NULL)
- status (VARCHAR 40, default "ready")
- updated_at (TIMESTAMP, auto-update)
Bootstrap Behavior
/api/apps ensures tn_apps exists.
If empty, it seeds:
- TezzNative Compiler
- TezzOS Builder
- TezzDB
This keeps first deploy functional without manual SQL.
DB Configuration
Create: web/tn_site/config/db.php
return [
'site_name' => 'TezzNative',
'site_url' => 'https://tn.tezzcorp.com',
'db_host' => 'localhost',
'db_name' => 'tezznative',
'db_user' => '...',
'db_pass' => '...',
'timezone' => 'UTC',
];
Operational Queries
# health
GET /api/health
# version metadata
GET /api/version
# app registry
GET /api/apps
# smoke validation
tezz test --smoke
Extending TezzDB
Recommended next schema:
- tn_packages (installed .gen package metadata)
- tn_services (service state + autostart policy)
- tn_users (auth and profile)
- tn_audit_log (ops log for transparency)
Keep backward compatibility with /api/apps while introducing new endpoints.
TezzNative App Packaging Direction
.gen package plan:
1) metadata manifest
2) checksum/signature
3) install hooks
4) service registration in tn_services
Use TezzNative CLI as the package/install frontend and TezzDB as source-of-truth backend.