mirror of
https://github.com/strapi/strapi.git
synced 2025-10-27 08:02:56 +00:00
Grammar and punctuation of models.md
Signed-off-by: Bart Duisters <bartduisters@bartduisters.com>
This commit is contained in:
parent
788ee8cc26
commit
4a49510d2d
@ -2,7 +2,7 @@
|
||||
|
||||
## Concept
|
||||
|
||||
Models are a representation of the database's structure and lifecycle. They are split into two separate files. A JavaScript file that contains the lifecycle callbacks, and a JSON one that represents the data stored in the database and their format. The models also allow you to define the relationships between them.
|
||||
Models are a representation of the database's structure and life cycle. They are split into two separate files. A JavaScript file that contains the life cycle callbacks, and a JSON one that represents the data stored in the database and their format. The models also allow you to define the relationships between them.
|
||||
|
||||
**Path —** `./api/restaurant/models/Restaurant.js`.
|
||||
|
||||
@ -47,16 +47,16 @@ module.exports = {
|
||||
}
|
||||
```
|
||||
|
||||
In this example, there is a `Restaurant` model which contains two attributes `cover`, `name` and `description`.
|
||||
In this example, there is a `Restaurant` model which contains the attributes `cover`, `name` and `description`.
|
||||
|
||||
### Where are the models defined?
|
||||
|
||||
The models are defined in each `./api/**/models/` folder. Every JavaScript or JSON file in these folders will be loaded as a model. They are also available through the `strapi.models` and `strapi.api.**.models` global variables. Usable everywhere in the project, they contain the ORM model object that they are refer to. By convention, models' names should be written in lowercase.
|
||||
The models are defined in each `./api/**/models/` folder. Every JavaScript or JSON file in these folders will be loaded as a model. They are also available through the `strapi.models` and `strapi.api.**.models` global variables. Usable everywhere in the project, they contain the ORM model object that they refer to. By convention, models' names should be written in lowercase.
|
||||
|
||||
## How to create a model?
|
||||
|
||||
::: tip
|
||||
If you are just starting out it is very convenient to generate some models with the Content Type Builder, directly in the admin interface. You can then review the generated model mappings on the code level. The UI takes over a lot of validation tasks and gives you a fast feeling for available features.
|
||||
If you are just starting out it is very convenient to generate some models with the Content Type Builder, directly in the admin interface. You can then review the generated model mappings on the code level. The UI takes over a lot of validation tasks and gives you a feeling for available features.
|
||||
:::
|
||||
|
||||
Use the CLI, and run the following command `strapi generate:model restaurant name:string description:text`. Read the [CLI documentation](../cli/CLI.md) for more information.
|
||||
@ -64,18 +64,18 @@ Use the CLI, and run the following command `strapi generate:model restaurant nam
|
||||
This will create two files located at `./api/restaurant/models`:
|
||||
|
||||
- `Restaurant.settings.json`: contains the list of attributes and settings. The JSON format makes the file easily editable.
|
||||
- `Restaurant.js`: imports `Restaurant.settings.json` and extends it with additional settings and lifecycle callbacks.
|
||||
- `Restaurant.js`: imports `Restaurant.settings.json` and extends it with additional settings and life cycle callbacks.
|
||||
|
||||
::: tip
|
||||
when you create a new API using the CLI (`strapi generate:api <name>`), a model is automatically created.
|
||||
When you create a new API using the CLI (`strapi generate:api <name>`), a model is automatically created.
|
||||
:::
|
||||
|
||||
## Model settings
|
||||
|
||||
Additional settings can be set on models:
|
||||
|
||||
- `connection` (string) - Connection's name which must be used. Default value: `default`.
|
||||
- `collectionName` (string) - Collection's name (or table's name) in which the data should be stored.
|
||||
- `connection` (string) - Connection name which must be used. Default value: `default`.
|
||||
- `collectionName` (string) - Collection name (or table name) in which the data should be stored.
|
||||
- `globalId` (string) -Global variable name for this model (case-sensitive).
|
||||
|
||||
**Path —** `Restaurant.settings.json`.
|
||||
@ -118,8 +118,8 @@ The info key on the model-json states information about the model. This informat
|
||||
|
||||
The options key on the model-json states.
|
||||
|
||||
- `idAttribute`: This tells the model which attribute to expect as the unique identifier for each database row (typically an auto-incrementing primary key named 'id'). _Only valid for bookshelf_
|
||||
- `idAttributeType`: Data type of `idAttribute`, accepted list of value below. _Only valid for bookshelf_
|
||||
- `idAttribute`: This tells the model which attribute to expect as the unique identifier for each database row (typically an auto-incrementing primary key named 'id'). _Only valid for bookshelf._
|
||||
- `idAttributeType`: Data type of `idAttribute`, accepted list of value below. _Only valid for bookshelf._
|
||||
- `timestamps`: This tells the model which attributes to use for timestamps. Accepts either `boolean` or `Array` of strings where first element is create date and second element is update date. Default value when set to `true` for Bookshelf is `["created_at", "updated_at"]` and for MongoDB is `["createdAt", "updatedAt"]`.
|
||||
- `uuid` : Boolean to enable UUID support on MySQL, you will need to set the `idAttributeType` to `uuid` as well and install the `bookshelf-uuid` package. To load the package you can see [this example](./configurations.md#bookshelf-mongoose).
|
||||
|
||||
@ -161,16 +161,17 @@ The following types are currently available:
|
||||
You can apply basic validations to the attributes. The following supported validations are _only supported by MongoDB_ connection.
|
||||
If you're using SQL databases, you should use the native SQL constraints to apply them.
|
||||
|
||||
- `required` (boolean) — if true adds a required validator for this property.
|
||||
- `unique` (boolean) — whether to define a unique index on this property.
|
||||
- `index` (boolean) — adds an index on this property, this will create a [single field index](https://docs.mongodb.com/manual/indexes/#single-field) that will run in the background (_only supported by MongoDB_).
|
||||
- `max` (integer) — checks if the value is greater than or equal to the given minimum.
|
||||
- `min` (integer) — checks if the value is less than or equal to the given maximum.
|
||||
- `required` (boolean) — If true, adds a required validator for this property.
|
||||
- `unique` (boolean) — Whether to define a unique index on this property.
|
||||
- `index` (boolean) — Adds an index on this property, this will create a [single field index](https://docs.mongodb.com/manual/indexes/#single-field) that will run in the background. _Only supported by MongoDB._
|
||||
- `max` (integer) — Checks if the value is greater than or equal to the given maximum.
|
||||
- `min` (integer) — Checks if the value is less than or equal to the given minimum.
|
||||
|
||||
**Security validations**
|
||||
To improve the Developer eXperience when developing or using the administration panel, the framework enhances the attributes with these "security validations":
|
||||
|
||||
- `private` (boolean) — if true, the attribute will be removed from the server response (it's useful to hide sensitive data).
|
||||
To improve the Developer Experience when developing or using the administration panel, the framework enhances the attributes with these "security validations":
|
||||
|
||||
- `private` (boolean) — If true, the attribute will be removed from the server response (it's useful to hide sensitive data).
|
||||
- `configurable` (boolean) - if false, the attribute isn't configurable from the Content Type Builder plugin.
|
||||
|
||||
### Example
|
||||
@ -188,7 +189,7 @@ To improve the Developer eXperience when developing or using the administration
|
||||
"unique": true
|
||||
},
|
||||
"description": {
|
||||
"default": "My descrioption",
|
||||
"default": "My description",
|
||||
"type": "text",
|
||||
"required": true
|
||||
},
|
||||
@ -199,7 +200,7 @@ To improve the Developer eXperience when developing or using the administration
|
||||
|
||||
## Relations
|
||||
|
||||
Relations let your create links (relations) between your Content Types.
|
||||
Relations let you create links (relations) between your Content Types.
|
||||
|
||||
:::: tabs
|
||||
|
||||
@ -241,7 +242,7 @@ xhr.send(
|
||||
|
||||
::: tab "One-to-One" id="one-to-one"
|
||||
|
||||
One-to-One relationships are usefull when you have one entity that could be linked to only one other entity. And vis versa.
|
||||
One-to-One relationships are usefull when you have one entity that could be linked to only one other entity. And vice versa.
|
||||
|
||||
#### Example
|
||||
|
||||
@ -290,7 +291,7 @@ xhr.send(
|
||||
|
||||
::: tab "One-to-Many" id="one-to-many"
|
||||
|
||||
One-to-Many relationships are usefull when an entry can be liked to multiple entries of an other Content Type. And an entry of the other Content Type can be linked to only one entry.
|
||||
One-to-Many relationships are usefull when an entry can be liked to multiple entries of another Content Type. And an entry of the other Content Type can be linked to only one entry.
|
||||
|
||||
#### Example
|
||||
|
||||
@ -349,7 +350,7 @@ xhr.send(
|
||||
|
||||
::: tab "Many-to-Many" id="many-to-many"
|
||||
|
||||
Many-to-Many relationships are usefull when an entry can be liked to multiple entries of an other Content Type. And an entry of the other Content Type can be linked to many entries.
|
||||
Many-to-Many relationships are usefull when an entry can be liked to multiple entries of another Content Type. And an entry of the other Content Type can be linked to many entries.
|
||||
|
||||
#### Example
|
||||
|
||||
@ -370,7 +371,7 @@ A `product` can be related to many `categories`, so a `category` can have many `
|
||||
```
|
||||
|
||||
**NOTE**:
|
||||
(NoSQL databases only) The `dominant` key defines which table/collection should store the array that defines the relationship. Because there are no join tables in NoSQL, this key is required for NoSQL databases (ex: MongoDB).
|
||||
(NoSQL databases only) The `dominant` key defines which table/collection should store the array that defines the relationship. Because there are no join tables in NoSQL, this key is required for NoSQL databases (e.g. MongoDB).
|
||||
|
||||
**Path —** `./api/category/models/Category.settings.json`.
|
||||
|
||||
@ -394,7 +395,7 @@ xhr.open('PUT', '/products/5c151d9d5b1d55194d3209be', true);
|
||||
xhr.setRequestHeader('Content-Type', 'application/json');
|
||||
xhr.send(
|
||||
JSON.stringify({
|
||||
categories: ['5c151d51eb28fd19457189f6', '5c151d51eb28fd19457189f8'], // Set of ALL categories linked to the product (existing categories + new category or - removed category)
|
||||
categories: ['5c151d51eb28fd19457189f6', '5c151d51eb28fd19457189f8'], // Set of ALL categories linked to the product (existing categories + new category or - removed category).
|
||||
})
|
||||
);
|
||||
```
|
||||
@ -403,11 +404,11 @@ xhr.send(
|
||||
|
||||
::: tab "Polymorphic" id="polymorphic"
|
||||
|
||||
The polymorphic relationships are the solution when you don't know which kind of model will be associated to your entry. A common use case is an `Image` model that can be associated to many others kind of models (Article, Product, User, etc).
|
||||
The polymorphic relationships are the solution when you don't know which kind of model will be associated to your entry. A common use case is an `Image` model that can be associated to many others kind of models (Article, Product, User, etc.).
|
||||
|
||||
#### Single vs Many
|
||||
|
||||
Let's stay with our `Image` model which might belongs to **a single `Article` or `Product` entry**.
|
||||
Let's stay with our `Image` model which might belong to **a single `Article` or `Product` entry**.
|
||||
|
||||
**NOTE**:
|
||||
In other words, it means that an `Image` entry can be associated to one entry. This entry can be a `Article` or `Product` entry.
|
||||
@ -578,10 +579,10 @@ CREATE TABLE `image_morph` (
|
||||
|
||||
::::
|
||||
|
||||
## Lifecycle callbacks
|
||||
## Life cycle callbacks
|
||||
|
||||
::: warning
|
||||
The life cycle functions are based on the ORM life cycle and not on the strapi request.
|
||||
The life cycle functions are based on the ORM life cycle and not on the Strapi request.
|
||||
We are currently working on it to make it easier to use and understand.
|
||||
Please check [this issue](https://github.com/strapi/strapi/issues/1443) on GitHub.
|
||||
:::
|
||||
@ -654,7 +655,7 @@ Callbacks on:
|
||||
|
||||
#### Mongoose
|
||||
|
||||
The entry is available through the `model` parameter
|
||||
The entry is available through the `model` parameter.
|
||||
|
||||
**Path —** `./api/user/models/User.js`.
|
||||
|
||||
@ -681,7 +682,7 @@ module.exports = {
|
||||
|
||||
#### Bookshelf
|
||||
|
||||
Each of these functions receives a three parameters `model`, `attrs` and `options`. You have to return a Promise.
|
||||
Each of these functions receives three parameters `model`, `attrs` and `options`. You have to return a Promise.
|
||||
|
||||
**Path —** `./api/user/models/User.js`.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user