Clean up model-version YAML schema, fix renderer, add compatibleVersions#631
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Database.versiondataset.dataset_versionbut unrelated to anything else — the frontend was comparing againstModel.version, so the version-switcher fade never matched its own writesModel.modelbin/agrammon.rakuGUI.version'7.0'); exposed inget_cfgasguiVersion. Falls through toModel.versionwhen not set so existing YAMLs keep workingVersions[].labelguiVersionModel.compatibleVersionsModel.versionstrings whose datasets this deployment will claim on first open. See belowdataset.dataset_versionnow sourced fromModel.version. Frontend fade in the dataset table now compares like-with-like.Model.compatibleVersionsfor cross-version editing. Without this, a dataset tagged'6.5.2'is unmodifiable from a v7 deployment (the(user, name, variant)lookup instore-variablefails). With it,Dataset.loadruns a one-shot UPDATE that promotes the row'sdataset_versionto the current deployment'sModel.versionon 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 withopacity:0.45which 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_versionwas set from the oldDatabase.version. After the upgrade, the running deployment looks for rows tagged with itsModel.versionand won't find legacy rows — listing keeps working but writes silently fail (NULLdata_dataset).db/migrate-dataset-version-source.sqlships anUPDATEtemplate. Run once per deployment after taking apg_dumpbackup; edit the version mapping (e.g.'6.0' → '6.6.0') to fit your deployment's history.Alternatively, set
Model.versionin 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 (coversVersions[].guiVersionfield rename in the existing positive test)make test— full suite against test DBModel.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)🤖 Generated with Claude Code