Data Source Reference

Lookup material for every supported data source: all authentication options (environment variables) and how data types are mapped when importing a contract and checked when testing one. For task-oriented walkthroughs, see Connect your Data.

How authentication works

Connection details (host, catalog, location, …) live in the contract's servers block; credentials are provided as environment variables. Variables are also loaded from a .env file in the current working directory (or the nearest parent directory containing one); already-set environment variables take precedence.

How data types work

A contract property carries up to two type declarations:

• logicalType — one of nine portable ODCS types: string, integer, number, boolean, date, timestamp, time, object, array.
• physicalType — free text for the native type in the data source (e.g. VARCHAR(255), NUMBER(38,0)). It is not validated by datacontract lint; at test time it is interpreted in the SQL dialect of the server under test.

When you run datacontract test, type checks work in one of two modes:

1. Native type check (Check that field x has physical type y) — on sources with catalog introspection (Snowflake, BigQuery, Databricks, Postgres, Redshift, SQL Server, Oracle, Trino, Athena), the declared physicalType is compared against the actual column type from the catalog. Timezone variants of timestamps are interchangeable; length/precision is only enforced when the contract declares it (varchar matches varchar(255), but varchar(255) does not match varchar(100)). A physicalType that can't be interpreted in the server's dialect degrades to the logical check or a warning — never a hard failure.
2. Logical type check (Check that field x has type y) — everywhere else (and as fallback), both the declared and the actual type are normalized to one of the nine ODCS categories and compared. integer and number are mutually compatible; a bare object or array matches any structure with the same base.

For file sources with format: csv, json, or avro, no type checks are generated — the file is read as the contract's types, and violations surface as read errors (plus JSON Schema validation for format: json).

Independent of the type checks, logicalTypeOptions (minimum, maximum, minLength, maxLength, pattern, enum, …) generate value checks that behave identically on every source.

Data sources

SnowflakeAuthentication and data typesGoogle BigQueryAuthentication and data typesDatabricksAuthentication and data typesPostgresAuthentication and data typesAmazon S3Authentication and data typesLocal filesData types for CSV, JSON, Parquet, DeltaAmazon AthenaAuthentication and data typesAmazon RedshiftAuthentication and data typesApache ImpalaAuthentication and data typesAzure Blob / ADLSAuthentication and data typesGoogle Cloud StorageAuthentication and data typesHTTP APIAuthentication and data typesKafkaAuthentication and data typesMicrosoft SQL ServerAuthentication and data typesMySQLAuthentication and data typesOracleAuthentication and data typesSpark DataFrameData types for in-memory DataFramesTrinoAuthentication and data types