Repository navigation
feat(ui): list the live catalog from the control API - #1344
Merged
Merged
Conversation
Add a person read of the current snapshot's nodes for a location target, with each node's declared metadata and its newest recorded build, and wire the Catalog page to it. The page hides the build-state, checks, owner and group parts the server does not report, links nodes only when node detail is available, and offers Execute only when ad hoc runs are supported.
The listing grouped the target's whole fingerprint history on every load, so its cost grew with history while it held the write transaction. Read each listed node's newest build with the exact-destination lookup node status uses, and bound the listing over 200,000 older builds with a time limit. A catalog filter whose control is hidden no longer narrows the list, so a shared status or group link cannot empty it.
One store round trip per node made a 3,000-node listing take about 0.6 s on PostgreSQL. Read the newest build of up to 100 nodes per statement, each still an exact seek on the node index, and bound a 3,000-node listing with a time limit on both stores.
Every wide node copied one build, so the guard could not tell whether a node received its own row. Each node now has a distinct build time and alternate nodes live in a named database, and the guard checks each node's own build.
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.
Why
The Catalog page only rendered mock data. The control API had no person read of a target's current nodes, so a live
sqb servercould not list what a location published or when each node was last built.Changes
GET /api/control/locations/{location_id}/targets/{target}/nodes(listPersonCatalogNodes), authorised like the jobs listing. Each record carries the current snapshot node's declared metadata (kind, name, path, materialization, description, tags, dependencies, relation, column count) and its newest recorded build, via node status's indexed exact-destination seek, 100 nodes per statement, so cost follows node count, not history. No SQL, Python source or config. Empty before the first publication.sqbrun. Lineage stays hidden.DuckShop: not applicable; a control API read and UI wiring, no compiler, Rules or project shape.
Verification
cargo test -p sqlbuild-orchestration --lib -- api::30/30, each on SQLite and PostgreSQL, including the denial and session role matrices. Time guards: 6 nodes over 200,010 builds under 100 ms (~4 ms; 458 ms with a grouped scan); 3,000 built nodes under 450 ms (~210 ms; 530–635 ms seeking per node).-D warnings,fensu check,make check-ci.npm run check,npm test65/65,npm run build.sqb serverwith a DuckDB location: 5 models with Name, Kind and Last built, a never-built model shows Never,?stale=1&group=…keeps all 5, Lineage and Execute hidden. Mock mode keeps every column, filter and Execute.