Documentation
¶
Overview ¶
Package project reads a directory of models and works out the order.
An edge is INFERRED from the SQL and then shown, which is the shape the spike's verdict asked for by name: the extractor reads 99.3% of real Postgres and nobody should find the other 0.7% at three in the morning. `brevis-sql graph` prints what was inferred, and `depends_on:` overrides it.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Function ¶
type Function struct {
Schema, Name string
// Path is as the project sees it, so an error names what somebody typed.
Path string
SQL string
}
Function is one SQL function the project owns.
THE SPIKE'S VERDICT PUT THESE IN M2 BY NAME. The most used macros in a real 625-model dbt project are expressions -- `trim_make_empty_string_null` at 1,674 uses, `generate_surrogate_key` at 268 -- and with those as SQL functions, 53% of its models need no template at all. That is the premise of this tool holding for half of a project nobody wrote for it.
The body is run VERBATIM and nothing here parses it. A function's text is `create or replace function …`, which is already idempotent in both dialects, and a tool that rewrote it would be guessing at a language it has no reason to read.
type Project ¶
type Project struct {
Models map[string]model.Model // by Ref(), `<schema>.<name>`
// Edges[a] are the models a reads. Only models: a reference to something
// this project does not define is a SOURCE, and sources have no edges
// because nothing here builds them.
Edges map[string][]string
Sources map[string][]string // by model, the references that are not models
// Functions are `functions/<schema>/<name>.sql`, in path order. They
// are run BEFORE the models and they are not models: no header, no
// materialisation, no tests, no place in the graph.
Functions []Function
}
Project is every model under a root, with the edges between them.
Source Files