For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

schema table column

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:

Complex relations are always on the source side of a relation so there is no need to search for this asset in incomingRelations.

Last updated

Was this helpful?