Make model_name optional for more discovery tools#289
Merged
DevonFulcher merged 2 commits intoAug 18, 2025
Conversation
DevonFulcher
deleted the
devon/Make_model_name_optional_for_more_discovery_tools
branch
August 18, 2025 14:50
theyostalservice
added a commit
that referenced
this pull request
Jul 2, 2026
theyostalservice
added a commit
that referenced
this pull request
Jul 7, 2026
#832) # Why `ResourceDetailsFetcher.fetch_details` resolves a resource by name (when no `unique_id` is given) by firing two `GetPackages` queries (macro + model packages) and then querying details for a Cartesian product of `{resource_type}.{package}.{name}` candidates across every package in the project. For model lookups this is wasteful: it enumerates macro packages the model can never belong to, and the candidate list grows with the number of packages in the project — all for a lookup the Discovery API can already do directly. # What Three commits, each independently reviewable: 1. **Add `ModelsFetcher.resolve_unique_ids_by_name`.** Resolves a model name to unique_id(s) via `applied.models(filter: {identifier: name})` — the same server-side filter `ModelsFetcher` already uses for `get_model_children`/`get_model_health`/etc. — reusing the existing paginated `fetch_models` path, so results aren't capped at a single page. `identifier` matches on the model's *alias* (DB relation name), not its dbt `name`, so results are filtered client-side to drop any node whose actual `name` doesn't match the query (prevents a same-aliased-but-differently-named model from being returned, which the old Cartesian path could never do). 2. **Wire `ResourceDetailsFetcher`'s `MODEL` branch through `ModelsFetcher`.** Replaces the packages-enumeration + Cartesian product for models with the new resolver — 2 GraphQL calls (resolve + details) instead of 3 (2x packages + details), with no guessed unique_ids. Other resource types (macro, source, exposure, test, seed, snapshot, semantic_model) are unchanged, since the generic resources filter they use doesn't support a name-based filter. 3. **Rewire `ModelPerformanceFetcher` to resolve names via `ModelsFetcher` directly**, instead of going through `ResourceDetailsFetcher.fetch_details` and discarding the full model-details payload (catalog, compiled code, etc.) it fetched only to read a `uniqueId`. **Known limitation, not introduced by this PR:** `get_model_details`'s name-based lookup has matched by alias/identifier rather than dbt `name` since #453, which switched it from a model-specific identifier filter to the generic multi-resource-type `fetch_details` mechanism while consolidating tools for the `search` feature. This PR keeps that alias-based matching (it just makes the lookup cheaper) and extends the same behavior to `get_model_performance`, which resolves names through the same path. As a result, a model whose alias was explicitly overridden away from its name (via `{{ config(alias=...) }}`) won't be found by name on `get_model_details`/`get_model_performance` — the same limitation `get_model_health`/`get_model_children`/`get_model_parents` have had since #289. See the comment below for the full history. Drafted by Claude Opus 4.8 under the direction of @theyostalservice.
alan-andrade
added a commit
that referenced
this pull request
Jul 8, 2026
## version: 1.21.2 ## v1.21.2 - 2026-07-08 ### Under the Hood * Model-by-name lookups in get_model_details now resolve via a single Discovery API identifier query instead of enumerating packages and guessing unique_ids. Note: this fast path matches by DB alias, which get_model_details has done since #453 (not something this change introduces) and which get_model_health/get_model_children/get_model_parents have done since #289 -- a model whose alias was explicitly overridden away from its dbt name may not be found by name. * get_model_performance's name resolution now skips fetching full model details (catalog, compiled code, etc.) and resolves the unique_id directly. * Update docs gen script to annotate deprecated tools to README ### Bug Fix * Reduce the semantic layer GraphQL request timeout from 60s to 30s so unresponsive requests fail faster instead of holding the connection open. Co-authored-by: alan-andrade <97609+alan-andrade@users.noreply.github.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.
Following from this PR: #268. The Discovery tools should have a more uniform function signature and handle parameters similarly.