Skip to main content
Version: 0.3.x

Data composition

Data composition is at the heart of ComposeDB, using composites as a proxy for datasets of documents relevant to applications and services.

Composites represent sets of models that can be used to query, create and update documents, therefore it is important for developers to identify models to use, whether by reusing models already adopted by the ecosystem in order to access the set of documents already created using these models, or creating new models that would better suit specific needs.

Models composition

The following schema describes how composites can be created by merging existing composites (composites D and A' below) and extracting models from a composite (composites E and F below).

The same datasets can be represented by different composites, such as the composites A and A' below that contain the same models.

Models composition schemaModels composition schema


The ComposeDB graph representation supports the following types of edges (relations) between nodes:

Direct edges between accounts are not supported by ComposeDB, but relations can be defined indirectly by using an intermediary document.

Account to document

The relations between documents and the account controlling (having created and being able to update) them are defined in the model used by the document.

ComposeDB currently supports two variants for these relations:

Account to single document

This variant ensures the indexing service stores at most one document of the given model for the account. This can be useful notably to store a profile or similar information.

These relations can be defined when creating new models, using the @createModel directive with the accountRelation argument set to SINGLE.

Account to multiple documents

This variant allows any number of documents of a given model to be associated to the account.

These relations can be defined when creating new models, using the @createModel directive with the accountRelation argument set to LIST.

Document to account

The ComposeDB runtime logic automatically replaces DID scalars defined in a schema by CeramicAccount objects, allowing to access the documents associated to the given account.

In order to make these fields directly queryable from the index, the schema must use the @accountReference directive on these fields.

Document to document

Relations between documents can be defined on fields using the StreamID scalar with the @documentReference directive specifying the model the related document must use. This allows to define many-to-one relations between documents, for example many "comment" documents to a single "post" document.

Using the ComposeDB runtime, the associated document can be accessed directly if a view using the @relationDocument directive is defined in the model.

It is also possible to represent one-to-many relations, for example one "post" document to many "comment" documents, by using the @relationFrom and @relationCountFrom directives to represent the other side of the relations.