Queries & mutations
In GraphQL, a query is used to fetch data and mutations are used to create/update or delete data. In Infrahub, a GraphQL query and 4 mutations will be generated for each model you define in the schema. The name of the query or mutation is based on the namespace and name of the model.
For example, for the model CoreRepository the following query and mutations have been generated:
Query: CoreRepository to fetchCoreRepositorynodes from InfrahubMutation: CoreRepositoryCreate to create aCoreRepositorynodeMutation: CoreRepositoryUpdate to update an existingCoreRepositorynodeMutation: CoreRepositoryUpsert to create or update aCoreRepositorynodeMutation: CoreRepositoryDelete to delete aCoreRepositorynode
Query format​
The top level query for each model will always return a list of objects and the query will have the following format CoreRepository > edges > node > display_label
query {
CoreRepository { # PaginatedCoreRepository object
count
edges { # EdgedCoreRepository object
node { # CoreRepository object
id
hfid
display_label
__typename
}
}
}
}
All list of objects will be nested under edges & node to make it possible to control the pagination and access the attribute count.
ID, hfid and display_label​
For all nodes, the attribute id, hfid and display_label are automatically available.
The value used to generate the display_label can be defined for each model in the schema. If no value has been provided a generic display label with the kind and the ID of the Node will be generated.
The value used to generate the hfid can be defined for each model in the schema. If no value has been provided and the model has a single uniqueness constraint defined, then the hfid will be automatically generated from the uniqueness constraint.
At the object level, there are mainly 3 types of resources that can be accessed, each with a different format:
AttributeRelationshipofCardinality OneRelationshipofCardinality Many
Attribute​
Each attribute is its own object in GraphQL to expose the value and all the metadata.
In the query below, to access the attribute name of the object the query must be CoreRepository > edges > node > name > value.
At the same level all the metadata of the attribute are also available, for example: is_protected, source & owner
query {
CoreRepository {
count
edges {
node {
name { # TextAttribute object
value
is_protected
source {
id
display_label
}
}
}
}
}
}
Relationship of Cardinality One​
A relationship to another model with a cardinality of One will be represented with a NestedEdged object composed of a node and a properties objects. The node gives access to the remote node (the peer of the relationship) while properties gives access to the properties of the relationship itself.
query {
CoreRepository {
count
edges {
node {
account {
properties {
is_protected
source {
id
display_label
}
}
node {
display_label
hfid
id
}
}
}
}
}
}
Relationship of Cardinality Many​
A relationship with a cardinality of Many will be represented with a NestedPaginated object composed. It was the same format as the top level PaginatedObject with count and edges but the child element will expose both node and properties. The node gives access to the remote node (the peer of the relationship) while properties gives access to the properties of the relationship itself.
query {
CoreRepository {
count
edges {
node {
tags { # NestedPaginatedBuiltinTag object
count
edges { # NestedEdgedBuiltinTag object
properties {
is_protected
source {
id
}
}
node {
display_label
hfid
id
}
}
}
}
}
}
}
Mutations format​
The format of the mutation to Create, Update and Upsert an object has some similarities with the query format. The format will be slightly different for:
- An
Attribute - A relationship of
Cardinality One - A relationship of
Cardinality Many
Create, update and upsert​
To Create, Update or Upsert an object, the mutations will have the following properties.
- The input for the mutation must be provided inside
data. - All mutations will return
okandobjectto access some information after the mutation has been executed. Updatemutations require you to provide anidorhfidto identify the object you want to update.Upsertmutations do not require you to provide theidor thehfid, but enough information needs to be provided for the back-end to uniquely identify the node. Typically this means that all the attribute or relationship values need to be provided that make up thehfidoruniqueness_constraintsof the node.
mutation {
CoreRepositoryCreate(
data: {
name: { value: "myrepop" }, # Attribute
location: { value: "myrepop" }, # Attribute
account: { hfid: ["my_account"] }, # Relationship One
tags: [ { hfid: ["my_tag"] } ]} # Relationship Many
) {
ok
object {
id
hfid
}
}
}
Delete​
For a Delete mutation, we have to provide the id or the hfid of the node as part of the data argument.
mutation {
CoreRepositoryDelete(data: {hfid: ["myrepo"]}) {
ok
}
}
Branch management​
In addition to the queries and the mutations automatically generated based on the schema, there are some queries and mutations to interact with the branches.
- Query:
Branch, Query a list of all branches - Mutation:
BranchCreate, Create a new branch - Mutation:
BranchUpdate, Update the description of a branch - Mutation:
BranchDelete, Delete an existing branch - Mutation:
BranchRebase, Rebase an existing branch with the main branch - Mutation:
BranchMerge, Merge a branch into main - Mutation:
BranchValidate, Validate if a branch has some conflicts