@baseView
A base view definition requires a single @baseView
type directives.
Example
type UserStatistics @baseView(sqlFile: "./userStatistics.sql") {
name: String! @index
numberOfUsers: Int!
}
The only object directives that are allowed for base views are @baseView
, @permission
and @filterByJwtData
.
The only allowed field directives are @index
and @permission
.
You can reference other projections (and CRUD types) in your base view schema. The GraphQL API will automatically fetch all referenced data.
Arguments
You can use the following arguments on the @baseView
directive directly:
Argument | Description |
---|---|
sqlFile | specify the path to the base view SQL file (relative) |
Argument sqlFile
The path in the sqlFile
argument has to be relative.
SELECT name AS name, COUNT(1) AS numberOfUsers FROM userView GROUP BY name
Reporting is an advanced topic. You need to understand the structure of your data on a relatively deep level. Therefore we let you create your reports by working directly on your data in your database:
- Every projection has a corresponding view that is named like the projection and suffixed by
view
. You can use this view to create your advanced view. - Each selected column is required to have an alias that matches the name of the field in the schema.
- References to other projections (and CRUD types) can be done by selecting the id of the referenced projection.
In case of array references you can use the
jsonb_agg
function to aggregate the ids:SELECT jsonb_agg(id) AS userList FROM user;
Limitations of the @baseView directive
Do not use the projection tables suffixed with a timestamp as they might get replaced by a new table having an other timestamp during deployments. Use the view that is named like the projection instead.
File as field type
You can use files as field types. When using the GraphQL API to fetch the view data, the result will be the ID
of the file.
You can query the CRUD GraphQL API to get more detailed file information like the mimeType
or the size
.