Models#

As Strapi is a headless Content Management System (CMS), creating a content structure for the content is one of the most important aspects of using the software. Models define a representation of the content structure.

There are 2 different types of models in Strapi:

• content-types, which can be collection types or single types, depending on how many entries they manage,
• and components that are content structures re-usable in multiple content-types.

If you are just starting out, it is convenient to generate some models with the Content-type Builder directly in the admin panel. The user interface takes over a lot of validation tasks and showcases all the options available to create the content's content structure. The generated model mappings can then be reviewed at the code level using this documentation.

Model creation#

Content-types and components models are created and stored differently.

Content-types#

Content-types in Strapi can be created:

• with the Content-type Builder in the admin panel,
• or with Strapi's interactive CLI strapi generate command.

The content-types use the following files:

• schema.json for the model's schema definition. (generated automatically, when creating content-type with either method)
• lifecycles.js for lifecycle hooks. This file must be created manually.

These models files are stored in ./src/api/[api-name]/content-types/[content-type-name]/, and any JavaScript or JSON file found in these folders will be loaded as a content-type's model (see project structure).

Components {#components-creation}#

Component models can't be created with CLI tools. Use the Content-type Builder or create them manually.

Components models are stored in the ./src/components folder. Every component has to be inside a subfolder, named after the category the component belongs to (see project structure).

Model schema#

The schema.json file of a model consists of:

• settings, such as the kind of content-type the model represents or the table name in which the data should be stored,
• information, mostly used to display the model in the admin panel and access it through the REST and GraphQL APIs,
• attributes, which describe the content structure of the model,
• and options used to defined specific behaviors on the model.

Model settings#

General settings for the model can be configured with the following parameters:

// ./src/api/[api-name]/content-types/restaurant/schema.json

{
  "kind": "collectionType",
  "collectionName": "Restaurants_v1",
}

Model information#

The info key in the model's schema describes information used to display the model in the admin panel and access it through the Content API. It includes the following parameters:

  "info": {
    "displayName": "Restaurant",
    "singularName": "restaurant",
    "pluralName": "restaurants",
    "description": ""
  },

Model attributes#

The content structure of a model consists of a list of attributes. Each attribute has a type parameter, which describes its nature and defines the attribute as a simple piece of data or a more complex structure used by Strapi.

Many types of attributes are available:

• scalar types (e.g. strings, dates, numbers, booleans, etc.),
• Strapi-specific types, such as:
  • media for files uploaded through the Media library
  • relation to describe a relation between content-types
  • customField to describe custom fields and their specific keys
  • component to define a component (i.e. a content structure usable in multiple content-types)
  • dynamiczone to define a dynamic zone (i.e. a flexible space based on a list of components)
  • and the locale and localizations types, only used by the Internationalization (i18n) plugin

The type parameter of an attribute should be one of the following values:

Validations#

Basic validations can be applied to attributes using the following parameters:

{
  // ...
  "attributes": {
    "title": {
      "type": "string",
      "minLength": 3,
      "maxLength": 99,
      "unique": true
    },
    "description": {
      "default": "My description",
      "type": "text",
      "required": true
    },
    "slug": {
      "type": "uid",
      "targetField": "title"
    }
    // ...
  }
}

Database validations and settings#

:::caution 🚧 This API is considered experimental.
These settings should be reserved to an advanced usage, as they might break some features. There are no plans to make these settings stable.
:::

Database validations and settings are custom options passed directly onto the tableBuilder Knex.js function during schema migrations. Database validations allow for an advanced degree of control for setting custom column settings. The following options are set in a column: {} object per attribute:

:::caution Draft & Publish and unique
When Draft & Publish is enabled, Strapi intentionally skips unique validations while an entry is saved as a draft. Duplicates therefore remain undetected until publication, at which point the database constraint triggers an error even though the UI previously displayed “Saved document” for the drafts.

To avoid unexpected publication failures:

• disable Draft & Publish on content-types that must stay globally unique,
• or add custom validation (e.g. lifecycle hooks or middleware) that checks for draft duplicates before saving,
• or rely on automatically generated unique identifiers such as a uid field and document editorial conventions.
  :::

{
  // ...
  "attributes": {
    "title": {
      "type": "string",
      "minLength": 3,
      "maxLength": 99,
      "unique": true,
      "column": {
        "unique": true // enforce database unique also
      }
    },
    "description": {
      "default": "My description",
      "type": "text",
      "required": true,
      "column": {
        "defaultTo": "My description", // set database level default
        "notNullable": true // enforce required at database level, even for drafts
      }
    },
    "rating": {
      "type": "decimal",
      "default": 0,
      "column": {
        "defaultTo": 0,
        "type": "decimal", // using the native decimal type but allowing for custom precision
        "args": [
          6,1 // using custom precision and scale
        ]
      }
    }
    // ...
  }
}

uid type#

The uid type is used to automatically prefill the field value in the admin panel with a unique identifier (UID) (e.g. slugs for articles) based on 2 optional parameters:

• targetField (string): If used, the value of the field defined as a target is used to auto-generate the UID.
• options (string): If used, the UID is generated based on a set of options passed to . The resulting uid must match the following regular expression pattern: /^[A-Za-z0-9-_.~]*$.

Relations#

Relations link content-types together. Strapi supports both single-entry relations (one-way and one-to-one) and multi relations where at least one side can point to several entries (one-to-many, many-to-one, many-to-many, and many-way). Multi relations are persisted as arrays in the database layer and are returned as arrays in the Content API responses.

Relations are explicitly defined in the attributes of a model with type: 'relation' and accept the following additional parameters:

One-to-One relationships are useful when one entry can be linked to only one other entry.

They can be unidirectional or bidirectional. In unidirectional relationships, only one of the models can be queried with its linked item.

  // …
  attributes: {
    category: {
      type: 'relation',
      relation: 'oneToOne',
      target: 'category',
    },
  },
  // …

  // …
  attributes: {
    category: {
      type: 'relation',
      relation: 'oneToOne',
      target: 'category',
      inversedBy: 'article',
    },
  },
  // …

  // …
  attributes: {
    article: {
      type: 'relation',
      relation: 'oneToOne',
      target: 'article',
      mappedBy: 'category',
    },
  },
  // …

One-to-Many relationships are useful when:

• an entry from a content-type A is linked to many entries of another content-type B,
• while an entry from content-type B is linked to only one entry of content-type A.

One-to-many relationships are always bidirectional, and are usually defined with the corresponding Many-to-One relationship:

  // …
  attributes: {
    owner: {
      type: 'relation',
      relation: 'manyToOne',
      target: 'api::person.person',
      inversedBy: 'plants',
    },
  },
  // …

  // …
  attributes: {
    plants: {
      type: 'relation',
      relation: 'oneToMany',
      target: 'api::plant.plant',
      mappedBy: 'owner',
    },
  },
  // …

Many-to-One relationships are useful to link many entries to one entry.

They can be unidirectional or bidirectional. In unidirectional relationships, only one of the models can be queried with its linked item.

  // …
  attributes: {
    author: {
      type: 'relation',
      relation: 'manyToOne',
      target: 'author',
    },
  },
  // …

  // …
  attributes: {
    author: {
      type: 'relation',
      relation: 'manyToOne',
      target: 'category',
      inversedBy: 'article',
    },
  },
  // …

  // …
  attributes: {
    books: {
      type: 'relation',
      relation: 'oneToMany',
      target: 'article',
      mappedBy: 'category',
    },
  },
  // …

Many-to-Many relationships are useful when:

• an entry from content-type A is linked to many entries of content-type B,
• and an entry from content-type B is also linked to many entries from content-type A.

Many-to-many relationships can be unidirectional or bidirectional. In unidirectional relationships, only one of the models can be queried with its linked item.

  // …
  attributes: {
    categories: {
      type: 'relation',
      relation: 'manyToMany',
      target: 'category',
    },
  },
  // …

  // …
  attributes: {
    tags: {
      type: 'relation',
      relation: 'manyToMany',
      target: 'tag',
      inversedBy: 'articles',
    },
  },
  // …

  // …
  attributes: {
    articles: {
      type: 'relation',
      relation: 'manyToMany',
      target: 'article',
      mappedBy: 'tag',
    },
  },
  // …

Custom fields#

Custom fields extend Strapi’s capabilities by adding new types of fields to content-types. Custom fields are explicitly defined in the attributes of a model with type: customField.

Custom fields' attributes also show the following specificities:

• a customField attribute whose value acts as a unique identifier to indicate which registered custom field should be used. Its value follows:
  • either the plugin::plugin-name.field-name format if a plugin created the custom field
  • or the global::field-name format for a custom field specific to the current Strapi application
• and additional parameters depending on what has been defined when registering the custom field (see custom fields documentation).

{
  // …
  "attributes": {
    "attributeName": { // attributeName would be replaced by the actual attribute name
      "type": "customField",
      "customField": "plugin::color-picker.color",
      "options": {
        "format": "hex"
      }
    }
  }
  // …
}

Components {#components-json}#

Component fields create a relation between a content-type and a component structure. Components are explicitly defined in the attributes of a model with type: 'component' and accept the following additional parameters:

{
  "attributes": {
    "openinghours": {
      "type": "component",
      "repeatable": true,
      "component": "restaurant.openinghours"
    }
  }
}

Dynamic zones#

Dynamic zones create a flexible space in which to compose content, based on a mixed list of components.

Dynamic zones are explicitly defined in the attributes of a model with type: 'dynamiczone'. They also accept a components array, where each component should be named following this format: <category>.<componentName>.

{
  "attributes": {
    "body": {
      "type": "dynamiczone",
      "components": ["article.slider", "article.content"]
    }
  }
}

Model options#

The options key is used to define specific behaviors and accepts the following parameter:

{
  "options": {
    "privateAttributes": ["id", "createdAt"],
    "draftAndPublish": true
  }
}

Plugin options#

pluginOptions is an optional object allowing plugins to store configuration for a model or a specific attribute.

{
  "attributes": {
    "name": {
      "pluginOptions": {
        "i18n": {
          "localized": true
        }
      },
      "type": "string",
      "required": true
    },
    "slug": {
      "pluginOptions": {
        "i18n": {
          "localized": true
        }
      },
      "type": "uid",
      "targetField": "name",
      "required": true
    }
    // …additional attributes
  }
}

Lifecycle hooks#

Lifecycle hooks are functions that get triggered when Strapi queries are called. They are triggered automatically when managing content through the administration panel or when developing custom code using queries·

Lifecycle hooks can be customized declaratively or programmatically.

Lifecycles hooks are not triggered when using directly the library instead of Strapi functions.

:::strapi Document Service API: lifecycles and middlewares
The Document Service API triggers various database lifecycle hooks based on which method is called. For a complete reference, see Document Service API: Lifecycle hooks. Bulk actions lifecycles (createMany, updateMany, deleteMany) will never be triggered by a Document Service API method. Document Service middlewares can be implemented too.
:::

Available lifecycle events#

The following lifecycle events are available:

• beforeCreate
• beforeCreateMany
• afterCreate
• afterCreateMany
• beforeUpdate
• beforeUpdateMany
• afterUpdate
• afterUpdateMany
• beforeDelete
• beforeDeleteMany
• afterDelete
• afterDeleteMany
• beforeCount
• afterCount
• beforeFindOne
• afterFindOne
• beforeFindMany
• afterFindMany

Hook event object#

Lifecycle hooks are functions that take an event parameter, an object with the following keys:

Declarative and programmatic usage#

To configure a content-type lifecycle hook, create a lifecycles.js file in the ./src/api/[api-name]/content-types/[content-type-name]/ folder.

Each event listener is called sequentially. They can be synchronous or asynchronous.

module.exports = {
  beforeCreate(event) {
    const { data, where, select, populate } = event.params;

    // let's do a 20% discount everytime
    event.params.data.price = event.params.data.price * 0.8;
  },

  afterCreate(event) {
    const { result, params } = event;

    // do something to the result;
  },
};

export default {
  beforeCreate(event) {
    const { data, where, select, populate } = event.params;

    // let's do a 20% discount everytime
    event.params.data.price = event.params.data.price * 0.8;
  },

  afterCreate(event) {
    const { result, params } = event;

    // do something to the result;
  },
};

Using the database layer API, it's also possible to register a subscriber and listen to events programmatically:

module.exports = {
  async bootstrap({ strapi }) {
// registering a subscriber
    strapi.db.lifecycles.subscribe({
      models: [], // optional;

      beforeCreate(event) {
        const { data, where, select, populate } = event.params;

        event.state = 'doStuffAfterWards';
      },

      afterCreate(event) {
        if (event.state === 'doStuffAfterWards') {
        }

        const { result, params } = event;

        // do something to the result
      },
    });

    // generic subscribe for generic handling
    strapi.db.lifecycles.subscribe((event) => {
      if (event.action === 'beforeCreate') {
        // do something
      }
    });
  }
}