Ilker ManapandClaude Opus 5
277add5ccb
The catalog can change while the cluster runs; this is where a change goes so it is still there tomorrow. Models declared in configuration and models added at runtime are two sources on purpose: config-as-code stays declarative and under review, and the database holds what someone added to try it. Configuration wins every conflict, and the direction matters. A request for a reviewed production model must never be answered by something added from a laptop, so a stored model colliding with a declared name is refused when it is added. A declared model cannot be removed at runtime either — it would return on the next restart, leaving the cluster disagreeing with its own config file until then, which is a worse answer than refusing and saying where to edit. The whole catalog is built before anything is written. A model naming a missing fallback, or colliding, or malformed in any of the ways catalog.New refuses, is rejected rather than persisted and then skipped forever after — a model that looks added and never appears is the worst outcome available. Removal is checked the same way, because another model may fall back to the one being removed, and a fallback pointing at nothing is discovered during the outage it was meant to cover. At startup each stored model is validated on its own against what is already accepted, so one bad row is skipped and named rather than taking the cluster with it. The declared models are precisely the ones that must survive that. Catalog types now carry json tags mirroring their koanf ones, so a stored definition is the same shape as the YAML someone writes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
26 lines
1.3 KiB
SQL
26 lines
1.3 KiB
SQL
-- Models added while the cluster is running.
|
|
--
|
|
-- The catalog came from a YAML file read once at startup, so adding a model
|
|
-- meant editing a file on the control plane and restarting it: a settling
|
|
-- window, adoption churn, and on one occasion two minutes of outage. That is a
|
|
-- reasonable way to manage a fixed production set and a bad one for a platform
|
|
-- whose promise is that people can try things.
|
|
--
|
|
-- These live alongside the ones in configuration rather than replacing them.
|
|
-- Config-as-code stays declarative — a model in YAML is in the catalog on every
|
|
-- start, whatever the database says — and this table holds the ones added
|
|
-- afterwards. A model added here may not take a name or alias that
|
|
-- configuration already uses, which the catalog's own constructor enforces for
|
|
-- free, because it refuses a duplicate whatever the source.
|
|
--
|
|
-- The definition is stored as JSON rather than as columns. A profile is a
|
|
-- nested, evolving shape, and every field added to it would otherwise be a
|
|
-- migration; the catalog already knows how to validate one, and a row that
|
|
-- fails validation is reported and skipped rather than blocking startup.
|
|
CREATE TABLE models (
|
|
name TEXT PRIMARY KEY,
|
|
definition TEXT NOT NULL,
|
|
created_at TIMESTAMP NOT NULL,
|
|
created_by TEXT NOT NULL DEFAULT ''
|
|
);
|