Prefix: lint_.
The linter’s findings: one row per finding, plus the corrections a rule can compute for its own findings. A correction here is a suggestion an editor may offer, never a rewrite the build performs. The family speaks the linter’s vocabulary, where severity follows from the rule.
Where to start
- lint_finding
-
One lint finding per row, in the linter’s own vocabulary.
- lint_finding_fix
-
The correction a rule computed for one of its own findings: a suggestion an editor offers, never a rewrite the build performs.
How this family meets the others
store_-
1 foreign key from this family’s rows into that one.
Why the name is right
The linter’s vocabulary (lint_finding.lint_rule is LintRule.id()), its own family because a lint finding’s severity is a function of its rule, never a rejection kind, and because lint rules are predicates over classified facts that should be free to migrate store-native without contending for another family’s relation.
lint_finding
One lint finding per row, in the linter’s own vocabulary. The loader’s input is the suppression-filtered warning list the report is assembled from, never a pre-suppression stream, so rows here are post-suppression survivors exactly as the report and the MCP tool carry them; a loader reading an earlier stream would resurrect disabled findings on the wire. Severity is warning by the rule’s nature and stated only in the union view, since one relation holds one vocabulary. Two shipped producers mint whole-build findings with no SDL coordinate (session-state and dependency-currency advisories), which is what puts this relation on the emit-order key convention.
Primary key: (graph_name, ordinal). Foreign key: (graph_name) references store_graph (graph_name).
graph_name(CHARACTER VARYING, not null)-
the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart
ordinal(INTEGER, not null)-
emit order in the suppression-filtered warning list, 0-based; the key’s tie-breaker on the javac_diagnostic convention
lint_rule(CHARACTER VARYING, not null)-
LintRule.id(), the finding’s stable rule identifier; the vocabulary this family is named for
message(CHARACTER VARYING, not null)-
the finding’s rendered message; display material, never a dimension
file(CHARACTER VARYING, nullable)-
path of the finding’s SDL source, on rejection_validation_error.file’s terms; NULL on the whole-build findings that carry no location
source_line(INTEGER, nullable)-
source line of the finding’s location, 1-based; NULL where unlocated
source_column(INTEGER, nullable)-
source column of the finding’s location, 1-based; NULL where unlocated
lint_finding_fix
The correction a rule computed for one of its own findings: a suggestion an editor offers, never a rewrite the build performs. Its own relation rather than a column on lint_finding, because a fix is optional per rule and per site: a description column on the finding would be nullable by kind, and its absence would then mean both "this rule suggests nothing" and "this finding has no fix here". A row is the presence of a fix and the edits are its ordered child. Deliberately not projected onto the diagnostic view, whose every dimension is single-valued at one row per diagnostic where a fix is a list; a reader wanting one joins these two relations on the finding it is offered for.
Primary key: (graph_name, finding_ordinal). Foreign key: (graph_name, finding_ordinal) references lint_finding (graph_name, ordinal).
graph_name(CHARACTER VARYING, not null)-
the owning graph’s partition, carried through the parent finding row
finding_ordinal(INTEGER, not null)-
the fixed finding’s ordinal in lint_finding’s emit order
description(CHARACTER VARYING, not null)-
the fix’s rendered title, which an editor shows as the label of the action; display material, never a dimension
lint_finding_fix_edit
One text edit of a fix: the half-open range [start, end) becomes the replacement, on the DDL’s standing pattern for an ordered multi-valued decode. The positions are positions in the text the finding was computed against, which is what makes a fix unsafe to apply to a text that has moved since: an edit names a span rather than a declaration, so unlike a coordinate it cannot be re-anchored by resolving the declaration again, and a reader is expected to check the source’s recorded stamp against the text in hand before offering one. An insertion is the zero-width case where start equals end and a deletion the empty replacement; both are stored as written rather than flagged, being readable from the columns.
Primary key: (graph_name, finding_ordinal, position). Foreign key: (graph_name, finding_ordinal) references lint_finding_fix (graph_name, finding_ordinal).
graph_name(CHARACTER VARYING, not null)-
the owning graph’s partition, carried through the parent fix row
finding_ordinal(INTEGER, not null)-
the fixed finding’s ordinal, the parent fix row’s key
position(INTEGER, not null)-
0-based position within the fix’s own edit list; order is the minted fact, since a rule may write two edits whose spans do not run in source order
start_line(INTEGER, not null)-
line of the replaced range’s inclusive start, 1-based per the graphql-java convention the finding’s own location follows
start_column(INTEGER, not null)-
column of the replaced range’s inclusive start, 1-based on the same convention
end_line(INTEGER, not null)-
line of the replaced range’s exclusive end, 1-based; equal to the start line on an insertion, and on every edit a rule writes today, a token never spanning a line
end_column(INTEGER, not null)-
column of the replaced range’s exclusive end, 1-based; equal to the start column on an insertion
replacement(CHARACTER VARYING, not null)-
the text the range becomes, exactly as the rule wrote it; empty on a deletion, which is the honest spelling of replacing a span with nothing