Documentation
¶
Overview ¶
Package check turns a model's `tests:` into SQL.
A TEST IS A SELECT THAT RETURNS VIOLATING ROWS. Zero rows is a pass, and there is nothing else to interpret: no exit code to read, no count to compare against a threshold somebody has to remember, and no second language to learn. It is dbt's shape and it is the right one -- the query that reports the failure is a query somebody can paste into a console and keep narrowing.
NOTHING HERE IS ON THE DIALECT INTERFACE except Literal, which is already there because it measurably differs. The four tests are standard SQL and both warehouses run the same text; adding a method per test kind would be an interface describing this package rather than describing a warehouse.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Check ¶
type Check struct {
Model string
Kind string
Column string
// Count is the query whose single value is how many rows break it.
Count string
// Sample is the query whose single value is ONE offending value, and it
// is empty when the kind has none worth showing: every row that breaks
// `not_null` breaks it by being NULL, and printing NULL back teaches
// nobody anything.
Sample string
}
Check is one assertion, ready to run.
type Failure ¶
type Failure struct {
Check
Rows int64
// Value is one offending value, when the kind has one worth showing.
// Empty for not_null, and empty when the sample query returned a NULL
// -- a duplicated NULL cannot happen, so an empty one here means the
// column held an empty string, which is a thing somebody needs to see
// as "" rather than as nothing.
Value string
}
Failure is a check that found rows.
type Result ¶
Result is the run.
func Run ¶
func Run(ctx context.Context, d dialect.Dialect, conn dialect.Conn, p *project.Project, order []string) (Result, error)
Run runs every test of every model in `order`.
IT DOES NOT STOP AT THE FIRST FAILURE, which is the opposite of Build and right for the opposite reason. A build that keeps going puts models on top of a relation that is not what their SQL assumed; a test run that stops hands somebody one problem at a time across four round trips to a warehouse. The whole report, once.
A query the warehouse REFUSES is still an error and does stop it: that is not a model failing its test, it is this package having written SQL the warehouse will not take, and continuing would bury it under results.
Source Files