fix too long fk names

docs/models/methods.md

@@ -10,6 +10,13 @@ Each model instance have a set of methods to `save`, `update` or `load` itself.
 
 Available methods are described below.
 
+## `pydantic` methods
+
+Note that each `ormar.Model` is also a `pydantic.BaseModel`, so all `pydantic` methods are also available on a model,
+especially `dict()` and `json()` methods that can also accept `exclude`, `include` and other parameters.
+
+To read more check [pydantic][pydantic] documentation
+
 ## load
 
 By default when you query a table without prefetching related models, the ormar will still construct
@@ -127,7 +134,7 @@ await track.delete() # will delete the model from database
 
 ## save_related
 
-`save_related(follow: bool = False) -> None`
+`save_related(follow: bool = False, save_all: bool = False, exclude=Optional[Union[Set, Dict]]) -> None`
 
 Method goes through all relations of the `Model` on which the method is called, 
 and calls `upsert()` method on each model that is **not** saved. 
@@ -138,16 +145,27 @@ By default the `save_related` method saved only models that are directly related
 
 But you can specify the `follow=True` parameter to traverse through nested models and save all of them in the relation tree.
 
+By default save_related saves only model that has not `saved` status, meaning that they were modified in current scope.
+
+If you want to force saving all of the related methods use `save_all=True` flag, which will upsert all related models, regardless of their save status.
+
+If you want to skip saving some of the relations you can pass `exclude` parameter. 
+
+`Exclude` can be a set of own model relations,
+or it can be a dictionary that can also contain nested items. 
+
+!!!note
+        Note that `exclude` parameter in `save_related` accepts only relation fields names, so
+        if you pass any other fields they will be saved anyway
+
+!!!note
+        To read more about the structure of possible values passed to `exclude` check `Queryset.fields` method documentation.
+
 !!!warning
     To avoid circular updates with `follow=True` set, `save_related` keeps a set of already visited Models, 
     and won't perform nested `save_related` on Models that were already visited.
     
     So if you have a diamond or circular relations types you need to perform the updates in a manual way.
-    
-    ```python
-    # in example like this the second Street (coming from City) won't be save_related, so ZipCode won't be updated
-    Street -> District -> City -> Street -> ZipCode
-    ```
 
 [fields]: ../fields.md
 [relations]: ../relations/index.md

docs/releases.md

@@ -1,6 +1,6 @@
 # 0.10.2
 
-## Features
+## ✨ Features
 
 * `Model.save_related(follow=False)` now accept also two additional arguments: `Model.save_related(follow=False, save_all=False, exclude=None)`.
   *  `save_all:bool` -> By default (so with `save_all=False`) `ormar` only upserts models that are not saved (so new or updated ones), 
@@ -19,7 +19,7 @@
 *  Same thing applies to `QuerysetProxy.update(each=False, **kwargs)` which also previously required that you either pass a `filter` (by `**kwargs` or as a separate `filter()` call) or set `each=True` now also accepts
     `exclude()` calls that generates NOT filter. So either `each=True` needs to be set to update whole table or at least one of `filter/exclude` clauses.
 
-## Fixes
+## 🐛 Fixes
 
 *  Fix improper relation field resolution in `QuerysetProxy` if fk column has different database alias.
 *  Fix hitting recursion error with very complicated models structure with loops when calling `dict()`.
@@ -28,7 +28,7 @@
 *  Fix bug when bulk_create would try to save also `property_field` decorated methods and `pydantic` fields
 *  Fix wrong merging of deeply nested chain of reversed relations
 
-## Other
+## 💬 Other
 
 *  Performance optimizations
 *  Split tests into packages based on tested area