Column-level overrides#
Target one specific column by its fully qualified table.column name:
[[sql.type_overrides]]
column = "users.metadata"
type = "json"Column-level overrides take precedence over database-type overrides that could otherwise also match.
Database-type overrides#
Target every column sharing a particular resolved type with db_type:
[[sql.type_overrides]]
db_type = "ltree"
type = "string"
[[sql.type_overrides]]
db_type = "citext"
type = "string"The match happens against the column's already-resolved neutral type name, not the raw DDL type as written.
Common override examples#
| Database Type | Neutral Type | Rust | Python | TypeScript | Go | Java |
|---|---|---|---|---|---|---|
ltree |
string |
String |
str |
string |
string |
String |
citext |
string |
String |
str |
string |
string |
String |
hstore |
json |
serde_json::Value |
dict |
Record<string, unknown> |
json.RawMessage |
String |
money |
decimal |
rust_decimal::Decimal |
decimal.Decimal |
string |
decimal.Decimal |
java.math.BigDecimal |
Type resolution pipeline#
Scythe resolves every type in three steps:
- SQL type — the type declared in your schema DDL (e.g.
CITEXT,LTREE). - Neutral type — an intermediate representation defined by the engine manifest.
- Language type — the concrete type in your target language.
Overrides intercept after step one. db_type matches against the already-resolved neutral type name, not the DDL type as written — so an override targeting db_type = "string" would match every column that resolves to a string, not just columns literally declared TEXT.
Planned#
Per-language type overrides — custom imports, wrapper types, and conversion expressions scoped to one backend rather than every backend — are on the roadmap but not yet available; today's type_overrides apply the same neutral type across every configured backend.
Related#
- Configuration — where
[[sql.type_overrides]]sits in the fullscythe.tomlschema. - Neutral Type Reference — every built-in neutral type this pipeline resolves to.