GraphQL Migrations operates on business models defined in your schema: These are GraphQL types decorated with a
Each type must have a primary key. You can specify one are one using the
@id annotation on a field.
Alternatively, you can use auto-incremented primary keys by having an
id field which mus be of type
GraphQL Migrations packages automatically adds a
NOT NULL constraint to all non null fields defined in the business model.
All primary keys are not nullable, irrespective of whether they are defined as non null or not.
The above model definition will result in the following table being created:
GraphQL Migrations will automatically create and index foreign keys once it sees relationships between business models.
This creates a relationship via a
userId column in the
profile table. You can customize the key tracking the relationship with the
profile.user_id in the database.
This specifies a relationship between
Comment.note and maps to
comment.noteId in the database.
key annotation you can customise the database column to map to.
This maps to
comment.note_id in the database.
To create a many-to-many relationship, add a model for your join table and use two one-to-many relationship mappings to create the relationship.
Let's see all of these in an example code below ran agains the PostgreSQL database:
This is a classic business model containing two types:
Comment, having a
oneToMany relationship between them.
From the relationship definition we can deduce that a
Note can have zero or many comments, inversely a
Comment can be about
Upon successfuly completion, the above migration will create the following layout in your database schema.
We can see notice that we have the
note_id_seq but not
comment_id_seq, this is because we are using auto-incremented
primary key for the
Note model and a custom primary key for the
Comment model. We will see how these looks like in details
for each model below:
Table details for the
Comment type shows that we have a
text as the primary key and
noteId as a foreign key on the
Note type because of the relationship we defined.
Here is how the
Note table looks like:
GraphQL Migrations created the auto-incremented primary key by inferring the usage of
id: ID! field on the
Additionally we can see that this primary key is referenced by the
comment table because of the relationship.
#Default field value
You can specify a default value using the
@default field annotation as shown below.
#Custom column type
You can specify a custom type usig the
@db field annotation as shown below:
By default string columns will be created as
varchar with a column length of
This can be configured to any length using the
@db field annnotation and the
Table or columns can be renamed using the
@db(oldNames: ['old']) annotation as shown below:
This will rename the
title and the table name to
note without data loss.
#Ignore a field
Sometimes our business model can contain more fields and some of these fields may only be there for representation purposes.
We can safely ignore generating columns for these fields using the
@db(skip: true) annotation on the corresponding field.
This annotation is not supported by Graphback CRUD.
When working with database migration library it is possible to change individual database columns.
This annotation is not supported by Graphback CRUD. When using custom name in database we need to map it directly inside resolver or db layer.
@index annotation can be used to create an index on a specific field. This annotation takes
name as argument representing
the name of the created index. If the name argument is left out, GraphQL Migrations will create one for you using the
The above model will result in the following indexes being created
@unique annotation can be used to create an unique constraint on a specific field. GraphQL Migrations will create the constraint name
The above model will result in the following constraint being created