Data types and schema
In order for the collaboration system to work, the following data must be able to be provided by your backend.
note
If you are using the default database, all of this data is provided by default, so you can skip this page.
info
The data in your database does not need to be stored exactly as specified below. You just need to be able to provide this data in your resolvers. If your data is stored in a different shape, you can use the resolvers to transform your spec into our spec.
#
Data types#
UsersYou must be able to provide the following information about users:
id
the user's unique IDemail
the user's emailtype
the type of user, eitherSTANDARD
orANONYMOUS
createdAt
the date the user was created (epoch timestamp in MS)updatedAt
the date the document was last updated (epoch timestamp in MS)
#
DocumentsYou must be able to provide the following information about documents
id
the document's unique IDauthorId
the ID of the user who created the documentcreatedAt
the date when the document was created (epoch timestamp in MS)updatedAt
the date when the document was last updated (epoch timestamp in MS)isPublic
whether or not the document is publicly viewablename
the name of the document
#
AnnotationsYou must be able to provide the following information about annotations
id
the annotation's unique IDxfdf
the XFDF command for the annotationauthorId
the ID of the user who created the annotationannotationId
the ID of the annotation generated by client side. May not necessarily be unique. If your database does not currently store this value, it can be parsed from the XFDF.documentId
the ID of the document that the annotation belongs topageNumber
the page number for the annotationcreatedAt
the date when the annotation was created (epoch timestamp in MS)updatedAt
the date when the annotation was last updated (epoch timestamp in MS)inReplyTo
the ID of the parent annotation
#
Document MembershipsYou must be able to provide the following information about a user's membership to a document.
In most existing systems, this table will not exist. In that case, you can just create one and store the following data.
id
the document membership's unique IDuserId
the ID of the user who this membership belongs todocumentId
the ID of the document that this membership belongs tolastRead
the date when the document was last read (epoch timestamp in MS)createdAt
the date when the membership was created (epoch timestamp in MS)updatedAt
the date when the member was last updated (epoch timestamp in MS)
#
Annotation MembershipsYou must be able to provide the following information about a user's membership to an annotation.
In most existing systems, this table will not exist. In that case, you can just create one and store the following data.
id
the annotation membership's unique IDuserId
the ID of the user who this membership belongs todocumentId
the ID of the document that this membership belongs toannotationId
the ID of the annotation this membership belongs tolastRead
the date when the annotation was last read (epoch timestamp in MS)createdAt
the date when the membership was created (epoch timestamp in MS)updatedAt
the date when the member was last updated (epoch timestamp in MS)annotationCreatedAt
the date when the associated annotation was created (epoch timestamp in MS)
#
MentionsYou must be able to provide the following information about a mention to an annotation.
In most existing systems, this table will not exist. In that case, you can just create one and store the following data.
id
the mention unique IDuserId
the ID of the user who this mention belongs todocumentId
the ID of the document that this mention belongs toannotationId
the ID of the annotation that this mention belongs tocreatedAt
the date the mention was created (epoch timestamp in MS)updatedAt
the date the mention was last updated (epoch timestamp in MS)
#
Snapshots (optional)If using the snapshots feature, you must be able to provide information about snapshots.
In most existing systems, this table will not exist. In that case, you can just create one and store the following data.
id
the snapshots unique IDauthorId
the user ID of the user who created the snapshotdocumentId
the ID of the document this snapshot belongs tpxfdf
the XFDF string for the snapshotname
the name of the snapshotcreatedAt
the date the mention was created (epoch timestamp in MS)updatedAt
the date the mention was last updated (epoch timestamp in MS)
#
Snapshot assets (optional)If using the snapshots feature, you must be able to provide information about snapshot assets.
In most existing systems, this table will not exist. In that case, you can just create one and store the following data.
id
the snapshot assets unique IDsnapshotId
the ID of the snapshot this asset belongs toodata
the base64 data of the assetcreatedAt
the date the mention was created (epoch timestamp in MS)updatedAt
the date the mention was last updated (epoch timestamp in MS)
#
Recommended database schemaIf you are starting from scratch or are creating new tables for collaboration, we recommend the following database structure. The following query is SQL, but can translate to any database.