Examples
Communities and domains
A community or domain tree, starting from top-level communities:
query {
communities(where: {parent: {_null: true}}) {
name
subCommunities {
name
subDomains {
name
}
}
subDomains {
name
}
}
}Domains filtered by the parent community name, including the parent community and responsibilities:
query {
domains(where: {parent: {name: {contains: "Data"}}}) {
name
parent {
name
}
responsibilities {
userGroup {
name
}
user {
fullName
}
}
}
}Domains that have at least one asset, including the first five assets:
Assets
Assets from a particular domain identified by ID, sorted by creation date, including asset tags:
Assets from a particular domain identified by name, having at least one attribute, including all attributes:
Assets filtered by attribute value, including the parent domain and two specific attributes:
An asset identified by ID, including all incoming and outgoing relations:
An asset with two different relation types:
Assets identified by the related asset ID and the relation type:
Assets with description attribute:
Schemas, tables, and columns

Top-down query (Schema → Table → Column):
Bottom-up query (Column → Table → Schema):
Mixed query (Table → Schema, Table → Column)
Please note the following tradeoffs for the above queries:
For the first query it might be difficult to set the limits in the right way as each schema can have a very different number of tables and the same thing happens for table to column relations.
The second query duplicates each table and schema multiple times thus making it more difficult to read.
The last query mixes both problems.
Sometimes you need to verify if the tree structure of the response is what you actually need. Consider using a query similar to the following example to specify the limits between all of the entities and still link them using the parent identifier:
Complex relations
Complex relations including all legs:
All complex relations related to a given asset:
Last updated
Was this helpful?