visualise schema changes #213

New issue

Closed

opened 2025-02-28 10:49:42 +01:00 by kiara · 1 comment

kiara commented

2025-02-28 10:49:42 +01:00

Owner

As a Fediversity user,
given I have a Fediversity deployment and the available options have updated since (#159),
when I open the deployment configuration panel,
I want changes in available options to be visualized,
so that I can make an informed decision on how to make use of them.

implementation notes

c.f. #143, which is about showing diffs but for data (rather than options)
in case of options coming from Nix (rather than JSON-Schema), should cover various operations (ideally extracted from e.g. markers, see #1073, or otherwise, see #628)
from the API (see #334) send old / new schemas and configuration values, rename mapping, optionally removals/additions and maybe type changes (see #629)
may come down to showing (color-code: red/yellow/green) + explaining in human language any potential changes (e.g. kinds + rename?) passed from the API
maybe complicated by version updates causing a mismatch between deployed state (unless we automatically do that?) vs config live-updated by the user.
e.g. /update?from=1 based on a JSONified VSC-tracker updates.yaml containing version option renames (at least those that could not be inferred from markers on relevant options) as k/v pairs (as add/rm could be inferred from schema diff):
```
1:
  old.option.name: new.option.name
```

**As** a Fediversity user, **given** I have a Fediversity deployment and the available options have updated since (#159), **when** I open the deployment configuration panel, **I want** changes in available options to be visualized, **so that** I can make an informed decision on how to make use of them. ### implementation notes - [x] c.f. #143, which is about showing diffs but for data (rather than options) - [ ] in case of options coming from Nix (rather than JSON-Schema), should cover various [operations](https://docs.confluent.io/platform/7.9/schema-registry/fundamentals/schema-evolution.html#summary) (ideally extracted from e.g. [markers](https://github.com/NixOS/nixpkgs/blob/511f22afbfaccda862e13f8f2441c717bc962e89/lib/modules.nix#L2203-L2226), see #1073, or otherwise, see #628) - [ ] from the API (see #334) send old / new schemas and configuration values, rename mapping, optionally removals/additions and maybe type changes (see #629) - [ ] may come down to showing (color-code: red/yellow/green) + explaining in human language any potential changes (e.g. [kinds](https://docs.rs/json-schema-diff/latest/json_schema_diff/enum.ChangeKind.html) + rename?) passed from the API - [ ] maybe complicated by version updates causing a mismatch between deployed state (unless we automatically do that?) vs config live-updated by the user. - [ ] e.g. `/update?from=1` based on a JSONified VSC-tracker `updates.yaml` containing version option renames (at least those that could not be inferred from markers on relevant options) as k/v pairs (as add/rm could be inferred from schema diff): ```yaml 1: old.option.name: new.option.name ```

Rows
Columns