Detector::Specification::Hasura
Hasura tracks tables in its metadata directory and generates GraphQL root fields for each. Two layouts exist and both are current:
- a flat
tables.yamlholding an array of- table: {...}entries - the CLI v3 layout, where
tables.yamlis only an index of"!include public_users.yaml"strings and each table lives in its own file as a top-level mapping
A detector written to the first shape alone finds nothing in a modern project, so both are accepted.
- table: on its own is a plausible shape in unrelated YAML (dbt
models, Airflow, Metabase), so a /metadata/ path segment is
required and the document must also carry a key from Hasura's own
permission/relationship vocabulary.
Constants
Keys that only a Hasura table definition carries, as one precompiled
alternation rather than a dozen String#includes? passes — each of
those is a full scan of the file.
Class methods
The tech name without needing an instance, so the registry can be read off the classes themselves rather than from a parallel list.
Instance methods
Cheap filename-only filter the detector pass uses to skip
detect on files the detector cannot possibly match. The
default true preserves prior behavior (every detector runs on
every file). Override with the same predicate the body of
detect starts with — e.g., filename.ends_with?(".py") for a
Python framework detector — so the detector loop avoids the
detect dispatch on files outside the detector's language.
On large codebases (saleor's 4255 .py files) this lifts ~100
virtual detect calls per file out of the hot loop because
most detectors' inner first-line is exactly this kind of cheap
filename check.
Memo safety: applicable? consults the path
(metadata/** directory gate), not just the basename.