archive-gh-me/typeorm
1
0
Fork 0
mirror of https://github.com/typeorm/typeorm.git synced 2025-12-08 21:26:23 +00:00
Code Issues Projects Releases Wiki Activity

Update relations.md

Browse Source 
Minor grammatical and punctuation error fixes.
This commit is contained in:
Matt Neal 2018-01-26 17:29:51 -05:00 committed by GitHub
parent a35a36a244
commit 088c80fbb6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/relations.md
View File

@ -25,7 +25,7 @@ There are several options you can specify for relations:
* `cascadeUpdate: boolean` - If set to true, the related object will be updated in the database on entity save.
* `cascadeRemove: boolean` - If set to true, the related object will be removed from the database on entity save and without related object.
* `cascadeAll: boolean` - Sets `cascadeInsert`, `cascadeUpdate`, `cascadeRemove` at once.
* `onDelete: "RESTRICT"|"CASCADE"|"SET NULL"` - specifies how foreign key should behave when referenced object is deleted
* `onDelete: "RESTRICT"|"CASCADE"|"SET NULL"` - specifies how foreign keys should behave when referenced object is deleted.
* `primary: boolean` - Indicates whether this relation's column will be a primary column or not.
* `nullable: boolean` - Indicates whether this relation's column is nullable or not. By default it is nullable.
It's not recommended to set it to false if you are using cascades in your relations.
@ -90,27 +90,27 @@ question.categories = [category1, category2];
await connection.manager.save(question);
```
As you can see in this example we did not called `save` for `category1` and `category2`.
As you can see in this example we did not call `save` for `category1` and `category2`.
They will be automatically inserted, because we set `cascadeInsert` to true.
When using `cascadeUpdate` `save` is called for each object in, that is in a relation with the entity being saved.
This means, that each entity in the relation will be automatically changed if they exist in the database.
When using `cascadeUpdate`, `save` is called for each object that is in a relation with the entity being saved.
This means that each entity in the relation will be automatically changed if they exist in the database.
When using `cascadeRemove` `remove` is called for each object missing in the relation.
Good example of this method is the relation between `Question` and `Answer` entities.
When you remove a `Question` which has `answers: Answer[]` relation you want to remove all answers from the database as well.
When using `cascadeRemove`, `remove` is called for each object missing in the relation.
A good example of this method is the relation between `Question` and `Answer` entities.
When you remove a `Question` which has an `answers: Answer[]` relation you want to remove all answers from the database as well.
Keep in mind - great power comes with great responsibility.
Cascades may seem a good and easy way to work with relations,
Cascades may seem like a good and easy way to work with relations,
but they may also bring bugs and security issues when some undesired object is being saved into the database.
Also, they provide a less explicit way of saving new objects into the database.
## `@JoinColumn` options
`@JoinColumn` not only defines which side of the relation contains the join column with a foreign key,
but also allows to customize join column name and referenced column name.
but also allows you to customize join column name and referenced column name.
When we set `@JoinColumn` it creates a column in the database automatically named `propertyName + referencedColumnName`.
When we set `@JoinColumn`, it automtically creates a column in the database named `propertyName + referencedColumnName`.
For example:
```typescript
@ -128,7 +128,7 @@ If you want to change this name in the database you can specify a custom join co
category: Category;
```
Join columns are always a reference to some columns (using a foreign key).
Join columns are always a reference to some other columns (using a foreign key).
By default your relation always refers to the primary column of the related entity.
If you want to create relation with other columns of the related entity -
you can specify them in `@JoinColumn` as well:
@ -140,7 +140,7 @@ category: Category;
```
The relation now refers to `name` of the `Category` entity, instead of `id`.
Column name for such relation will become `categoryName`
Column name for that relation will become `categoryName`
## `@JoinTable` options
@ -165,5 +165,5 @@ You can also change the name of the generated "junction" table.
categories: Category[];
```
If destination table has composite primary keys,
then array of properties must be send to `@JoinTable`.
If the destination table has composite primary keys,
then an array of properties must be sent to `@JoinTable`.