26 lines
1.4 KiB
SQL
26 lines
1.4 KiB
SQL
-- Ein eigenes Schreibbudget je Projekt.
|
|
--
|
|
-- ── Warum? ───────────────────────────────────────────────────────────────────
|
|
--
|
|
-- Ein gültiger API-Key umgeht die IP-Sperre bewusst (siehe APIAuth in
|
|
-- internal/web/middleware.go). Damit hat ein Agent, der in einer Schleife hängt,
|
|
-- überhaupt keine Grenze mehr — er schreibt, bis die Platte voll ist.
|
|
--
|
|
-- Die Obergrenze hängt am Projekt und nicht am Key: Ein Limit je Key ließe sich
|
|
-- umgehen, indem man einen zweiten Key anlegt, und das darf jeder Projekt-Admin
|
|
-- selbst.
|
|
--
|
|
-- ── Warum die Vorgabe 0 und nicht die eigentliche Zahl? ──────────────────────
|
|
--
|
|
-- 0 heißt hier nicht "darf nicht schreiben", sondern "keine eigene Angabe —
|
|
-- es gilt der Standard aus WRITE_LIMIT_HOURLY". Damit muss diese Migration
|
|
-- keine Daten anfassen: Alle bestehenden Projekte bekommen automatisch den
|
|
-- Standardwert, und der lässt sich später in der Umgebung ändern, ohne jede
|
|
-- Zeile nachzuziehen.
|
|
--
|
|
-- Die eigentliche Zahl steht bewusst NICHT als Vorgabewert im Schema. Sonst
|
|
-- gäbe es zwei Orte, an denen ein Standard festgelegt ist, und irgendwann
|
|
-- widersprechen sie sich.
|
|
|
|
-- ALTER TABLE ... ADD COLUMN können SQLite und PostgreSQL gleichermaßen.
|
|
ALTER TABLE projects ADD COLUMN write_limit_hourly INTEGER NOT NULL DEFAULT 0;
|