Versioning and conflict resolution
@versioned
The @versioned
directive adds object versioning and conflict resolution to a type. Do not use this directive when leveraging DataStore as the conflict detection and resolution features are automatically handled inside AppSync and are incompatible with the @versioned
directive.
Definition
1directive @versioned(versionField: String = "version", versionInput: String = "expectedVersion") on OBJECT
Usage
Add @versioned
to a type that is also annotate with @model
to enable object versioning and conflict detection for a type.
1type Post @model @versioned {2 id: ID!3 title: String!4 version: Int! # <- If not provided, it is added for you.5}
Creating a Post automatically sets the version to 1
1mutation Create {2 createPost(input:{3 title:"Conflict detection in the cloud!"4 }) {5 id6 title7 version # will be 18 }9}
Updating a Post requires passing the "expectedVersion" which is the object's last saved version
Note: When updating an object, the version number will automatically increment.
1mutation Update($postId: ID!) {2 updatePost(3 input:{4 id: $postId,5 title: "Conflict detection in the cloud is great!",6 expectedVersion: 17 }8 ) {9 id10 title11 version # will be 212 }13}
Deleting a Post requires passing the "expectedVersion" which is the object's last saved version
1mutation Delete($postId: ID!) {2 deletePost(3 input: {4 id: $postId,5 expectedVersion: 26 }7 ) {8 id9 title10 version11 }12}
Update and delete operations will fail if the expectedVersion does not match the version
stored in DynamoDB. You may change the default name of the version field on the type as well as the name
of the input field via the versionField and versionInput arguments on the @versioned
directive.
Generates
The @versioned
directive manipulates resolver mapping templates and will store a version
field in versioned objects.