Repository navigation
refactor(api,search): drop status predicates — D1 holds only status='ok' - #146
Merged
Merged
Conversation
Since #145 the sync removes any row whose status isn't 'ok', migration 013 cleared the rest, and production confirms it (netixlan: 66,006 rows, all 'ok'). Every status predicate was redundant: the default status='ok' filter in the query builder, depth expansion and through-sets, compare, and keyword/graph search. An explicit ?status= still filters like any field (ok → everything, anything else → nothing). Besides less SQL, child-id lookups become index-only: depth=1's SELECT id, <fk> FROM child WHERE <fk> IN (…) now uses the FK index as a COVERING INDEX instead of fetching each child row to check status. Test fixtures that seeded deleted/pending rows (a state D1 can no longer hold) are removed; the sync test from #145 covers the invariant. Co-Authored-By: Claude Opus 5.5 <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
2 participants
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.
Since #145 the sync removes any row whose status isn't
ok, migration013(released in v0.22.7) cleared the rest, and production confirms it:SELECT status, COUNT(*) FROM peeringdb_network_ixlan GROUP BY status→ok 66006. Every status predicate in the worker queries is therefore redundant.Removed
api/query.js: the defaultstatus = 'ok'clause. An explicit?status=still filters like any field:okreturns everything, anything else returns nothing.api/depth.js: the predicates in child sets (depth 1 and 2), parent expansion and through-sets.api/handlers/compare.js: all of them.search/: keyword, graph-hydration and graph-search lookups.filterByMetadatanow omitsWHEREwhen no metadata predicate remains.Why it's also faster
Child-id lookups become index-only. depth=1's
SELECT id, <fk> FROM child WHERE <fk> IN (…)previously had to fetch each child row to checkstatus. SQLite's plan changes fromUSING INDEX peeringdb_network_facility_net_id_idxtoUSING COVERING INDEX peeringdb_network_facility_net_id_idx. The same applies to every FK-based set lookup.Tests
query.test.js: the default-status assertions now assert there is no status clause; the explicit?status=case is kept.upstream_compat_sqlite.test.js: removed fixtures that seeded adeletedlink and apendingcampus, a state D1 can no longer hold, and the expansion-level pending tests. The invariant is tested where it's enforced, in fix(sync): D1 holds only status='ok' rows #145's sync test.🤖 Generated with Claude Code