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).
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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).
Implemented in
5d44103.Settings now live in
~/Library/Application Support/de.rfc1437.ds4server/config.yaml, besidedata.sqlite3, grouped asmodel,idle_timeout_minutes,endpoint,generation,runtimeandinterface. 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:
The
preferencestable and its Diesel model are dropped by a migration; per the issue no values are migrated.