You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rename the metric triple and the parameter set field (#1009)
## The renames
Three renames and the migration one of them needs. No behavior change.
### `JsonMetric` -> `JsonMetricTriple`
A `JsonMetric` is a value with its two bounds: the triple a metric row
used to be
before named values existed. The plain name read like the whole of what
a metric is,
which it is not any more. This is a type rename only. Every serde field
that carries
one keeps its own name (`JsonAlert.metric`, `JsonPerfMetric.metric`, and
the rest), so
not one response byte changes. The OpenAPI component and the TypeScript
type follow.
### `JsonReportParameter.parameters` -> `set`
The object is already named `parameter` where a report result carries
it, so the field
spelled its parent again. It now spells what it holds:
```json
"parameter": { "uuid": "...", "set": { "size_mb": 16 } }
```
This one does change report response bytes. It is free right now: no
released CLI
deserializes the report `parameter` object, so nothing in the wild reads
the old
spelling. Once the next release ships a client that does, the same
rename becomes a
break. The type name `JsonReportParameter` is unchanged.
The BMF v1 **input** format is untouched. A report still submits
`"parameters"` on each
entry, and every adapter fixture stays as it was.
### `JsonParameters` -> `ParameterSet`
The type has been called a parameter set in its own prose since it was
written. It is
an internal newtype with a hand written `JsonSchema` impl, so the
component name is
renamed there as well, and the typeshare mapping follows.
## The migration
`2026-08-23-120000_parameter_set` renames the `parameter.parameters`
column to
`parameter.set`, and the model fields follow it (`QueryParameter.set`,
`InsertParameter.set`, `UpdateParameter.set`).
`set` is an SQL keyword, so the migration and the raw SQL that reads the
column quote
it. Diesel quotes identifiers of its own accord, so the DSL needs
nothing.
The migration is metadata only:
```sql
ALTER TABLE parameter RENAME COLUMN parameters TO "set";
```
SQLite rewrites the stored DDL in place, `UNIQUE(benchmark_id, "set")`
and the index
that backs it included, without reading a row. `down.sql` is the
reverse, and just as
cheap.
Migrations already written keep the spelling that was true when they
ran: the
migrations that create and read `parameter.parameters` are history and
are left alone.
The one seed in the migration tests that hand writes a `parameter` row
below this
layer now does so in raw SQL under the old column name, which is what
the schema at
that point in the chain has; the chain renames it on the way back up.
## Gates
- `cargo fmt -- --check`
- `cargo clippy --no-deps --all-targets --all-features -- -Dwarnings`
- `cargo nextest run --all-features --profile ci`, `cargo test --doc
--all-features`
- `cargo check --no-default-features`
- `cargo gen-types`, with the regenerated spec and TypeScript types
committed
0 commit comments