Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
var (
ErrorEngineNotSupported = errors.New("engine not supported")
)
Functions ¶
This section is empty.
Types ¶
type AnalyzeRelationFunc ¶
type AnalyzeRelationFunc func(ctx context.Context, sql string, cat catalog.Provide) ([]model.ColumnRelation, error)
AnalyzeRelationFunc analyzes exactly one statement and returns its column relations. It must not accept multi-statement input itself: the split lives above the dialects, or every engine ends up with its own multi-statement policy and they disagree — which is how one engine came to analyze a MANUAL_SQL script whole while another rejected it and the runner cleared the object's lineage.
type Analyzer ¶
type Analyzer struct {
// contains filtered or unexported fields
}
Analyzer resolves SQL against an explicit set of per-engine analyzers and the catalog they read metadata from.
The set is a value the caller owns rather than package state an init function fills in: which engines exist is a compile-time fact, and a process that holds its own analyzer cannot have the registry change under it — or disagree with a test about what is registered.
func NewAnalyzer ¶
func NewAnalyzer(cat catalog.Provide, registrations ...EngineRegistration) *Analyzer
NewAnalyzer assembles an analyzer over cat and an explicit set of engines. A duplicate engine is a programming error in the assembly list, not a runtime condition: it means two dialects claim the same engine.
func (*Analyzer) Analyze ¶
func (a *Analyzer) Analyze(ctx context.Context, engine storepb.Engine, sql string) ([]model.ColumnRelation, error)
Analyze analyzes every statement in sql and returns their merged column relations.
The script is split here, at the boundary above the dialects, because a dialect analyzer is defined for exactly one statement: it resolves names against a scope built from that one statement, and sharing the scope across statements made an unqualified column in a later statement resolve against an earlier one's relations.
A statement that cannot be parsed fails the whole script, and the caller is expected to discard what it stored for the object: nothing about a script whose text does not parse can be trusted. A statement an analyzer merely cannot represent is different — its diagnostics are reported beside the edges the other statements produced, so a coverage gap never discards real lineage.
func (*Analyzer) SplitScript ¶
SplitScript splits a script into the statements it holds, using engine's splitter.
Analyze splits internally, so a caller that has to see each statement on its own — the application-SQL ingest path fingerprints them separately — must cut the script exactly the same way. It asks here rather than reaching for a splitter of its own, because two splitters would eventually disagree about what one statement is.
An unregistered engine yields nothing; an engine registered without a splitter yields its input whole, which is what Analyze does with it.
type EngineRegistration ¶
type EngineRegistration struct {
Engine storepb.Engine
Analyze AnalyzeRelationFunc
// Split may be nil for an analyzer defined for a whole script.
Split ScriptSplitter
}
EngineRegistration binds one engine to its single-statement analyzer and the splitter that feeds it one statement at a time. A dialect exports one, and the process assembles the whole set where it is built.
type ScriptSplitter ¶
ScriptSplitter splits a script into the statements it contains, dropping the ones that carry no SQL (blank lines and comments). It is a lexical scan, so it works on text the parser would reject; parsing stays the analyzer's job.
type UnsupportedStatementError ¶
type UnsupportedStatementError struct {
// Diagnostics lists what the analysis could not represent, in the order it
// found it, deduplicated and bounded.
Diagnostics []model.Diagnostic
// Omitted counts the diagnostics the bound left out, so the message says how
// many it does not name instead of hiding them.
Omitted int
}
UnsupportedStatementError reports a *partial* analysis: SQL that parsed but contains something the analyzer could not represent — a statement shape it does not model, or a reference that resolved to nothing. The relations returned alongside it are the ones it did find, and a caller is expected to keep them, while the diagnostics say what is missing so a gap never reads as "this input has no lineage".
They are structured rather than a sentence because the causes call for different action: "not modelled" is a coverage gap in the analyzer, "unresolved reference" is usually the SQL naming something it cannot see, and a caller that only has the text can act on neither. Error renders them the way an operator log and a stored version message carry them.
A parse error is not this: unparseable input yields no result at all, and an analyzer reports that with its own error type rather than this one.
func (*UnsupportedStatementError) Error ¶
func (e *UnsupportedStatementError) Error() string
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package algorithm holds the parts of lineage analysis that do not depend on the SQL dialect: how a lineage edge is identified for deduplication, how a row-set predicate is attributed to the scope whose rows it decides, and how the arms of a set operation merge.
|
Package algorithm holds the parts of lineage analysis that do not depend on the SQL dialect: how a lineage edge is identified for deduplication, how a row-set predicate is attributed to the scope whose rows it decides, and how the arms of a set operation merge. |
|
Package engines assembles the SQL lineage analyzers this build supports.
|
Package engines assembles the SQL lineage analyzers this build supports. |
|
Package mariadb provides direct lineage analysis for MariaDB queries.
|
Package mariadb provides direct lineage analysis for MariaDB queries. |
|
Package mysql provides direct lineage analysis for MySQL queries.
|
Package mysql provides direct lineage analysis for MySQL queries. |
|
gen
command
Command gen copies the shared MySQL-family analyzer body into the TiDB and MariaDB packages.
|
Command gen copies the shared MySQL-family analyzer body into the TiDB and MariaDB packages. |
|
Package postgresql provides direct lineage analysis for PostgreSQL queries.
|
Package postgresql provides direct lineage analysis for PostgreSQL queries. |
|
Package starrocks provides direct lineage analysis for StarRocks queries.
|
Package starrocks provides direct lineage analysis for StarRocks queries. |
|
Package testutil provides common test utilities for lineage analysis tests.
|
Package testutil provides common test utilities for lineage analysis tests. |
|
Package tidb provides direct lineage analysis for TiDB queries.
|
Package tidb provides direct lineage analysis for TiDB queries. |