Skip to content

Save named sets of parameter values on a database - #685

Merged
ccomb merged 2 commits into
mainfrom
scenarios
Oct 17, 2026
Merged

ccomb merged 2 commits into
mainfrom
scenarios

Conversation

@ccomb

@ccomb ccomb commented Oct 17, 2026

Copy link
Copy Markdown
Owner

Save named sets of parameter values on a database

A scenario is a name and the parameter values that make it, such as
"high salt" for salt_kg at 0.02. GET /db/{db}/scenarios lists them,
PUT /db/{db}/scenarios/{name} saves one, replacing what that name held,
and DELETE /db/{db}/scenarios/{name} drops it. To score one, a client
sends its values as the parameters of a scoring request, so the engine
never scores a scenario by name.

Scenarios are kept in a journal of their own, scenarios/journal.jsonl
in the database's upload directory, apart from the database's journal:
saving one changes nothing in the database, so it must not look like an
edit to the cache or to a replay. Nothing is held in memory; each listing,
save and drop reads that file.

Refused, with the reason: values a scoring request would refuse (an
unknown parameter, a formula, a process that is not there), a scenario
that sets nothing, a drop of a name that holds none, and any save on a
database the engine reads from its configuration, where the scenario
would be lost at the next restart. A scenario that an edit of the
database has since made unusable is listed with the problem. A copy of a
database takes its scenarios along.

The assistant has list_scenarios, save_scenario and drop_scenario,
and pyvolca scenarios(), save_scenario() and drop_scenario(). Wire
revision 75.

ccomb added 2 commits October 17, 2026 12:43
A scenario is a name and the parameter values that make it, such as
"high salt" for `salt_kg` at 0.02. `GET /db/{db}/scenarios` lists them,
`PUT /db/{db}/scenarios/{name}` saves one, replacing what that name held,
and `DELETE /db/{db}/scenarios/{name}` drops it. To score one, a client
sends its values as the parameters of a scoring request, so the engine
never scores a scenario by name.

Scenarios are kept in a journal of their own, `scenarios/journal.jsonl`
in the database's upload directory, apart from the database's journal:
saving one changes nothing in the database, so it must not look like an
edit to the cache or to a replay. Nothing is held in memory; each listing,
save and drop reads that file.

Refused, with the reason: values a scoring request would refuse (an
unknown parameter, a formula, a process that is not there), a scenario
that sets nothing, a drop of a name that holds none, and any save on a
database the engine reads from its configuration, where the scenario
would be lost at the next restart. A scenario that an edit of the
database has since made unusable is listed with the problem. A copy of a
database takes its scenarios along.

The assistant has `list_scenarios`, `save_scenario` and `drop_scenario`,
and pyvolca `scenarios()`, `save_scenario()` and `drop_scenario()`. Wire
revision 75.
… around it

A scenario named "mix 50/50" or "salt #2" reached the engine as another
path, or cut short: pyvolca now percent-encodes every value it puts in a
path. A name with a space at either end was saved as typed, so it could
not be told from the name without the space: it is now refused. The
scenario name gets its own type, so it cannot be swapped with the name of
the database beside it.
@ccomb ccomb added the agent-reviewed pr-cycle ran label Oct 17, 2026
@ccomb
ccomb merged commit 6580ca1 into main Oct 17, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agent-reviewed pr-cycle ran

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant