Skip to content

Clean up model-version YAML schema, fix renderer, add compatibleVersions#631

Merged
zaucker merged 5 commits into
oposs:mainfrom
zaucker:model-version-cleanup
May 19, 2026
Merged

Clean up model-version YAML schema, fix renderer, add compatibleVersions#631
zaucker merged 5 commits into
oposs:mainfrom
zaucker:model-version-cleanup

Conversation

@zaucker
Copy link
Copy Markdown
Contributor

@zaucker zaucker commented May 19, 2026

Summary

Cleans up the version-related YAML schema and adds the missing piece that lets two sibling deployments share datasets across the version switcher (PR #629).

Schema cleanup — two redundant fields removed, one added:

Field Status Why
Database.version removed Tagged dataset.dataset_version but unrelated to anything else — the frontend was comparing against Model.version, so the version-switcher fade never matched its own writes
Model.model removed Never read by any code path; the model directory is selected by the positional arg to bin/agrammon.raku
GUI.version added (optional) Short user-visible version label (e.g. '7.0'); exposed in get_cfg as guiVersion. Falls through to Model.version when not set so existing YAMLs keep working
Versions[].label renamedguiVersion Always was the sibling's user-visible version, not a free-form label
Model.compatibleVersions added (optional) List of foreign Model.version strings whose datasets this deployment will claim on first open. See below

dataset.dataset_version now sourced from Model.version. Frontend fade in the dataset table now compares like-with-like.

Model.compatibleVersions for cross-version editing. Without this, a dataset tagged '6.5.2' is unmodifiable from a v7 deployment (the (user, name, variant) lookup in store-variable fails). With it, Dataset.load runs a one-shot UPDATE that promotes the row's dataset_version to the current deployment's Model.version on first open, after which the existing strict lookup finds the row. Set on both sides for round-trip editing across two sibling deployments.

Renderer bug fixes. The dataset-table row renderer added in #629 used qx.bom.Font.getDefaultStyles() (browser default → Times New Roman) instead of the qx theme font, and faded mismatched rows with opacity:0.45 which DevTools flagged as failing WCAG AA contrast. Now uses the themed font and an accessible muted color (#555, ~7.5:1 on white) plus italic.

Migration

Required if you have datasets from before this change. Their dataset_version was set from the old Database.version. After the upgrade, the running deployment looks for rows tagged with its Model.version and won't find legacy rows — listing keeps working but writes silently fail (NULL data_dataset).

db/migrate-dataset-version-source.sql ships an UPDATE template. Run once per deployment after taking a pg_dump backup; edit the version mapping (e.g. '6.0' → '6.6.0') to fit your deployment's history.

Alternatively, set Model.version in YAML to the legacy short value ('6.0') — no DB change required, but you lose the granular identifier and the original namespace conflation comes back.

Test plan

  • prove6 -l t/config.rakutest — passes (covers Versions[].guiVersion field rename in the existing positive test)
  • make test — full suite against test DB
  • Manual: configure two sibling deployments, each listing the other in Model.compatibleVersions; create a dataset on deployment A, switch to B via the version switcher, open the dataset, verify it loads + edits work; switch back to A and verify it now appears faded (B claimed it)
  • Manual: confirm DevTools no longer reports contrast warnings on the dataset table rows

🤖 Generated with Claude Code

zaucker and others added 5 commits May 19, 2026 11:11
Two issues with the row renderer landed in dfc3fd4 / b1a3ea4:

  - The constructor used qx.bom.Font.getDefaultStyles(), which returns
    the BROWSER default font (serif → Times New Roman on most systems).
    Resolve the qooxdoo theme's default font instead so cells render in
    the same typeface as the rest of the app.

  - Mismatch rows used opacity:0.45. DevTools flagged this as a WCAG
    AA contrast failure: opacity stacking drops the effective text
    contrast below 4.5:1 even though the source color is still black.
    Use a muted color (oposs#555 = ~7.5:1 on white) plus italic for the
    mismatch cue instead. Real color → accurate contrast check, italic
    keeps the row visually distinct.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two yaml fields had been driving the same concept in different namespaces
or were never read at all:

  - Database.version was the source of dataset.dataset_version (via
    Agrammon::Config.agrammon-variant), but had no semantic relationship
    to anything else. Frontend compared against Model.version, so the
    version-switcher fade never matched its own writes.

  - Model.model named the model directory under share/Models, but no
    code path actually read it — the directory is selected via the
    positional argument to `bin/agrammon.raku web <model>/End.nhd`.

Drop both fields. agrammon-variant.version now sources from Model.version,
so dataset rows are tagged with the same identifier the frontend uses,
and the dataset-table fade in the version switcher compares like-with-like.

Migration: existing production rows keep their old dataset_version
values (e.g. '6.0'); they'll appear as "mismatched" in the new fade
until either updated by an UPDATE statement or the running deployment's
Model.version is set to match the historical value.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Split the two roles 'version' had been playing in the YAML:

  - Model.version is the internal identifier — sourced into the
    dataset_version column, matched against Versions[].version in the
    switcher, used at startup to locate the model directory.

  - GUI.version (new, optional) is the short user-visible label
    ('7.0', '6.5.2'). Exposed in get_cfg as `guiVersion`. Falls through
    to Model.version when not set, so existing deployments keep
    working without YAML changes.

Versions[].label is renamed to Versions[].guiVersion — it always was
the sibling's user-visible label, not a free-form string. The schema
doc in etc/agrammon.yaml.dist, the dropdown label in OptionMenu.js,
the t/config.rakutest assertions, and the agrammon.cfg-with-versions
fixture are updated to match.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dataset.dataset_version is now sourced from Model.version (was
Database.version). Existing rows tagged with the old short Database.version
values ('6.0', '7.0') need a one-time UPDATE before the running
deployment can modify them — the (user, name, variant) lookup in
store-variable won't find legacy rows otherwise.

db/migrate-dataset-version-source.sql ships the UPDATE template (run
once per deployment, edit the version mappings to fit your history,
take a pg_dump backup first). CHANGELOG explains all four breaking
field changes (Database.version drop, Model.model drop, GUI.version
add, Versions[].label rename) and points at the migration script.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
New optional YAML field: deployments declare which other Model.version
strings they accept datasets from. On first open of a foreign-version
dataset, Dataset.load runs a one-shot UPDATE that promotes the row's
dataset_version to the current deployment's Model.version. Subsequent
operations (store-variable, rename, delete) then find the row via the
existing strict (user, name, variant) lookup.

Plumbing: Config.model-compatible-versions reads the list, Config.
agrammon-variant carries it through, Agrammon::DB::Variant exposes it
to subclasses via the private !compatible-versions helper. Dataset.
!ensure-version-match is the UPDATE itself; called at the top of
Dataset.load. The UPDATE filters by (user, name, gui-variant,
model-variant, dataset_version = ANY(compat)) — same scoping as
every other dataset query — so it can't clobber unrelated rows.

Empty / omitted list = strict mode (existing behavior unchanged for
deployments that don't opt in). For round-trip editing across two
sibling deployments, set compatibleVersions on BOTH sides — opening
a dataset on either claims it for that deployment until the next
open elsewhere.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@zaucker zaucker merged commit f5b1890 into oposs:main May 19, 2026
2 checks passed
@zaucker zaucker deleted the model-version-cleanup branch May 19, 2026 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant