Skip to content

chore: move metric snapshots to meta database #197 - #199

Open
buhaiovos wants to merge 4 commits into
developmentfrom
feat/197-prepare-metrics-snapshots
Open

buhaiovos wants to merge 4 commits into
developmentfrom
feat/197-prepare-metrics-snapshots

Conversation

@buhaiovos

@buhaiovos buhaiovos commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator

Applicable issues

Description of changes

Problem

run_metric_snapshots lived in the analytics database, but it is not analytics data — it is per-computation configuration (captured metric bindings, declaration versions, output schemas). Sitting there cost three things: no referential integrity (deleteRun silently orphaned every snapshot row, since no cross-database FK is possible), no joins with run metadata (every consumer read runs from meta and snapshots from analytics and joined in the JVM), and a ClickHouse liability (a UNIQUE(computation_id, tsmd_id) upsert table is exactly what should not be reimplemented on a column store when the analytics vendor is swapped). The REST path /api/v1/analytics/run-metric-snapshots was already inaccurate, and its OpenAPI example files were misnamed so they were silently never injected. Doing this now unblocks the enriched test-suite-run listing (#197), which needs metricNames per run and should be built against the final data shape.

Solution

  • The table is recreated in meta (V1.32 SQL) with FOREIGN KEY (test_suite_run_id) REFERENCES test_suite_runs(id) ON DELETE CASCADE, and existing rows — which are not regenerable — are copied across by the repository's first Flyway Java migration (V1_33), registered explicitly via .javaMigrations(...) so it can be constructor-injected with the analytics DataSource
  • The migration skips absent source tables (fresh installs), skips rows whose run no longer exists, and the meta Flyway bean now takes the analytics Flyway bean as a parameter to make the ordering deterministic.
  • Models, mappers, repository, service and DTOs move out of the analytics packages, qualifiers flip to their meta counterparts
  • The endpoint moves to /api/v1/run-metric-snapshots, with the old path kept as a separate @Deprecated(forRemoval = true) controller (non-breaking for the UI), and gains the OpenAPI examples
  • The analytics table is left in place, frozen and unread, and excluded from the analytics jOOQ generator so there is exactly one generated binding - dropping it and removing the alias are deliberately deferred.
  • Covered by a dedicated two-container migration test plus updated functional suites (snapshot helpers moved to MetaTestDataHelper), with specs and docs synced.

Checklist

  • corresponding issue(s) linked in the "Development" section of sidebar and referenced in "Applicable issues" section above
  • I have read the "Description of changes" and understood it


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ai-dial-actions

This comment has been minimized.

@buhaiovos
buhaiovos marked this pull request as ready for review September 14, 2026 15:09
@buhaiovos
buhaiovos added this pull request to stack #203 September 16, 2026 09:53
@ai-dial-actions

Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@buhaiovos buhaiovos changed the title chore: move metric snapshots to meta store #197 chore: move metric snapshots to meta database #197 Sep 16, 2026
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.

3 participants