30 releases 32 tags

RSS feed

• v0.23.0 687b624b5e

  Compare

  v0.23.0 — the published tables Stable

  joeyr released this 2026-08-05 23:32:50 -05:00 | 110 commits to main since this release

  Added

  • Every artifact is now also published into Postgres, sliced per champion and
    role. This is Phase 1 of docs/query-api-plan.md:
    lol-companion currently downloads whole files — 12.5 MB per refresh, of which
    the 7.6 MB synergies artifact has no consumer at all — and the endgame is a
    small read-only service that answers for the champions a user actually plays.
    Nothing reads the tables yet.

    Three tables. published_artifact holds the generatedFrom block, the file's
    other top-level siblings (tierList, perks/styles, items), the sha256
    of the rendered file and the file itself brotli'd. published_entry holds one
    row per (champion, role). published_current names the patch each artifact is
    serving. One transaction per artifact, with the current pointer moved last, so
    a reader that resolves a patch can never then find its entries missing.

    champion-damage.json is stored whole and deliberately not split: its record
    has no role dimension, and the damage bars need all ten champions on the board
    anyway.

    The split is verified every night rather than trusted. sliceArtifact
    rebuilds the file from its own rows, re-renders it, and refuses to publish
    unless the bytes match what was committed. Slicing is the one operation that
    can turn a validated artifact into a wrong answer — a subset is
    indistinguishable from a complete one — and a silently dropped champion or role
    is exactly the failure the classic coverage guards exist to catch. Measured
    across all ten artifacts on patch 16.15: 565 ms of slicing, 2.6 s including the
    writes, against a three-hour window.

    Storage on that patch: 4.8 MB of entries and 960 KB of archives. Entries are
    pruned to the same two-patch window the crawl rows use; the brotli'd payloads
    are not, because they are what preserves the data/archive guarantee.

  • scripts/verify-published.mjs. Checks each row's sha256 against the file
    committed at its raw URL, which is what makes running both publish targets at
    once checkable rather than hopeful. Needs the database reachable.

  • PUBLISH_DB_ENABLED (default on) backs the database publish out without
    touching the commit. Independent of PUBLISH_ENABLED: they are two outputs
    with two audiences.

  Changed

  • The Forgejo commit is now rendered once and the bytes shared with the local
    *_OUT write and the slice, so all three are provably the same file.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads