58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
# 049 — Store profiles inline in `settings.json` instead of a separate `profiles.json`
|
|
|
|
## Summary
|
|
|
|
Profile data is currently persisted as its own file, separate from
|
|
`settings.json`. `Settings` (`src/settings.rs:68`) only holds a `Profiles`
|
|
pointer struct (`names`, `active_profile`, `profiles_dir`, `src/settings.rs:56-63`)
|
|
while the actual `Profile`/`Dashboard`/param and metric declarations live in
|
|
`ProfileStore`, serialized as a single `profiles.json` inside
|
|
`profiles_dir` (`src/profile.rs:1` doc comment, `profiles_store_path` at
|
|
`src/profile.rs:491-492`, loaded/saved via `ProfileStore::load`/`save` at
|
|
`src/profile.rs:503,557`). Every mutation path in `ProfileStore` (create,
|
|
delete, record_param_declaration, record_metric_declaration,
|
|
create_dashboard, save_dashboard, delete_dashboard, set_active, etc.)
|
|
takes both a `store_path` and, separately, `settings`/`settings_path` to
|
|
keep the two files in sync. This ticket folds profile storage into
|
|
`settings.json` so there's a single source of truth file instead of two
|
|
files that must be kept consistent.
|
|
|
|
## Scope
|
|
|
|
- Move the profile list (currently `ProfileStore.profiles: Vec<Profile>`)
|
|
into `Settings` itself, replacing the `Profiles { names, active_profile,
|
|
profiles_dir }` pointer struct with the actual profile data (keep
|
|
`active_profile` as a field alongside it).
|
|
- Update `ProfileStore` (or fold it directly into `Settings`) so all
|
|
mutation methods read/write through the single `settings.json` via
|
|
`Settings::save`/`Settings::load`, instead of maintaining a separate
|
|
`store_path`/`profiles_store_path`.
|
|
- Write a one-time migration: on load, if a legacy `profiles.json` exists
|
|
under the configured `profiles_dir` and `settings.json` has no inline
|
|
profiles yet, read it in, merge into `Settings`, save, and (after a
|
|
successful save) remove or rename the old file so it isn't re-migrated.
|
|
- Update every call site currently passing both a settings path and a
|
|
profiles store path (`src/api.rs`, `main.rs`, tests in `src/profile.rs`)
|
|
to the new single-path API.
|
|
- Keep CSS import/export (`src/settings.rs` `import_css`/`link_css`,
|
|
which already write separate CSS files referenced from `settings.json`)
|
|
as-is — this ticket is scoped to profiles only.
|
|
|
|
## Acceptance criteria
|
|
|
|
- A fresh install has exactly one persisted file, `settings.json`,
|
|
containing profiles, dashboards, and declarations inline — no
|
|
`profiles.json` is created.
|
|
- An existing installation with a legacy `profiles_dir/profiles.json` is
|
|
migrated automatically on next load: profiles appear inline in
|
|
`settings.json`, and the old file is removed/renamed so migration
|
|
doesn't repeat on subsequent loads.
|
|
- All existing profile/dashboard/declaration CRUD behavior (create,
|
|
delete, set active, record param/metric declarations, dashboard CRUD)
|
|
is unchanged from the user's perspective, verified by porting the
|
|
existing `src/profile.rs` tests to operate against `Settings` directly.
|
|
|
|
## Depends on
|
|
|
|
None.
|