move preferences from database to yaml file #26

Closed
opened 2026-07-26 07:30:55 +00:00 by hugo · 1 comment
Owner

the config should be a structured yaml file beside the database, so that users easily can change config values there or via agent, too. this is a greenfield implementation, so no migration for prefs from database to config necessary. config should only list values that are actually set (non-empty) and the defaults should be have the same as with database (setting not set, default value used).

the config should be a structured yaml file beside the database, so that users easily can change config values there or via agent, too. this is a greenfield implementation, so no migration for prefs from database to config necessary. config should only list values that are actually set (non-empty) and the defaults should be have the same as with database (setting not set, default value used).
hugo added the enhancement label 2026-07-26 07:30:55 +00:00
Author
Owner

Implemented in 5d44103.

Settings now live in ~/Library/Application Support/de.rfc1437.ds4server/config.yaml, beside data.sqlite3, grouped as model, idle_timeout_minutes, endpoint, generation, runtime and interface. Only values that differ from the defaults are written, so an untouched configuration is an empty file and anything missing falls back to the default the database used to hold. The file is validated when it is read: a missing file is simply the defaults, a malformed or out-of-range one is reported instead of silently reset.

Example after changing a few settings:

model: glm-5.2
generation:
  context_tokens: 65536
  reasoning_mode: none
runtime:
  ssd:
    enabled: true
    cache: 64GB

The preferences table and its Diesel model are dropped by a migration; per the issue no values are migrated.

Implemented in 5d44103. Settings now live in `~/Library/Application Support/de.rfc1437.ds4server/config.yaml`, beside `data.sqlite3`, grouped as `model`, `idle_timeout_minutes`, `endpoint`, `generation`, `runtime` and `interface`. Only values that differ from the defaults are written, so an untouched configuration is an empty file and anything missing falls back to the default the database used to hold. The file is validated when it is read: a missing file is simply the defaults, a malformed or out-of-range one is reported instead of silently reset. Example after changing a few settings: ```yaml model: glm-5.2 generation: context_tokens: 65536 reasoning_mode: none runtime: ssd: enabled: true cache: 64GB ``` The `preferences` table and its Diesel model are dropped by a migration; per the issue no values are migrated.
hugo closed this issue 2026-07-26 07:50:56 +00:00
Sign in to join this conversation.