@model directive on an object type definition to describe a data model. The
table (table name) and
pk (primary key) arguments are both required.
Mapping fields to columns
Any fields on the type will be included in the model as columns. By default, the column names will be expected to match the field names, but you may configure a transformation to apply to the field name (like
SNAKE_CASE) to generate the appropriate column name. The
transformFieldNames option must be provided through the
@sqlmancer directive. To explicitly associate a field with a differently named column, use the
@col directive. To not have a field included in the model at all, use the
It's possible to create virtual or computed fields by using the
@depend directive. The columns passed to the directive's
on argument will be added to the SQL query (if the field is requested) and can then be used inside the field's resolver. Note that the model may not include all of a table's columns, but any column can be passed to the
on argument, even if it's not part of the model.
Private fields and models
Sometimes a field needs to be available through the client, but shouldn't be exposed as a field in the GraphQL schema. For example, we might want to access a
password column but not actually expose this column in our API. You can use the
@private directive to remove this fields from your schema while still enabling the client to write to them.
@private directive can also be applied to object types, interfaces and unions, allowing you to add models to the database client without actually exposing these models as types in the schema.
Sqlmancer can model either tables or views in your database. Since views cannot be written to, it's helpful to indicate any models that utilize a view as being read-only. A read-only model has no methods for creating, updating or deleting its records.
You can also define inline views right in your schema using common-table expressions (CTEs). This allows you to create arbitrary views of your underlying data without having to write any migrations. Models for inline views still require a
pk argument, but omit the
table argument and instead provide a
cte argument. These models are always read-only. Here's an example that combines multiple tables into a single view: