collerek
diff --git a/‎docs/models/inheritance.md
Lines changed: 3 additions & 5 deletions b/‎docs/models/inheritance.md
Lines changed: 3 additions & 5 deletions
diff --git a/‎docs/models/methods.md
Lines changed: 47 additions & 47 deletions b/‎docs/models/methods.md
Lines changed: 47 additions & 47 deletions
@@ -7,7 +7,7 @@ Out of various types of ORM models inheritance `ormar` currently supports two of
 
 ## Types of inheritance
 
-The short summary of different types of inheritance is:
+The short summary of different types of inheritance:
 
 * **Mixins [SUPPORTED]** - don't subclass `ormar.Model`, just define fields that are
   later used on different models (like `created_date` and `updated_date` on each model),
@@ -126,8 +126,6 @@ class Category(DateFieldsModel, AuditModel):
 The list of inherited options/settings is as follows: `metadata`, `database`
 and `constraints`.
 
-Also methods decorated with `@property_field` decorator will be inherited/recognized.
-
 Of course apart from that all fields from base classes are combined and created in the
 concrete table of the final Model.
 
@@ -143,7 +141,7 @@ inheritance.
 Whenever you define a field with same name and new definition it will completely replace
 the previously defined one.
 
-```python
+```python hl_lines="28"
 # base class
 class DateFieldsModel(ormar.Model):
     ormar_config = OrmarConfig(
@@ -324,7 +322,7 @@ Person.ormar_config.model_fields
 Similarly, you can inherit from Models that have ManyToMany relations declared but
 there is one, but substantial difference - the Through model. 
 
-Since in the future the Through model will be able to hold additional fields and now it links only two Tables 
+Since the Through model will be able to hold additional fields, and now it links only two Tables 
 (`from` and `to` ones), each child that inherits the m2m relation field has to have separate
 Through model. 
 
 
@@ -13,37 +13,37 @@ 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 `model_dump()` and `json()` methods that can also accept `exclude`, `include` and other parameters.
+especially `model_dump()` and `model_dump_json()` methods that can also accept `exclude`, `include` and other parameters.
 
 To read more check [pydantic][pydantic] documentation
 
-## construct
+## model_construct()
 
-`construct` is a raw equivalent of `__init__` method used for construction of new instances.
+`model_construct` is a raw equivalent of `__init__` method used for construction of new instances.
 
-The difference is that `construct` skips validations, so it should be used when you know that data is correct and can be trusted.
+The difference is that `model_construct` skips validations, so it should be used when you know that data is correct and can be trusted.
 The benefit of using construct is the speed of execution due to skipped validation.
 
 !!!note 
-        Note that in contrast to `pydantic.construct` method - the `ormar` equivalent will also process the nested related models.
+    Note that in contrast to `pydantic.model_construct` method - the `ormar` equivalent will also process the nested related models.
 
 !!!warning
-        Bear in mind that due to skipped validation the `construct` method does not perform any conversions, checks etc. 
-        So it's your responsibility to provide that data that is valid and can be consumed by the database.
-        
-        The only two things that construct still performs are:
+    Bear in mind that due to skipped validation the `construct` method does not perform any conversions, checks etc. 
+    So it's your responsibility to provide that data that is valid and can be consumed by the database.
+    
+    The only two things that construct still performs are:
 
-        *  Providing a `default` value for not set fields
-        *  Initialize nested ormar models if you pass a dictionary or a primary key value
+    *  Providing a `default` value for not set fields
+    *  Initialize nested ormar models if you pass a dictionary or a primary key value
 
-## dict
+## model_dump()
 
-`dict` is a method inherited from `pydantic`, yet `ormar` adds its own parameters and has some nuances when working with default values,
+`model_dump` is a method inherited from `pydantic`, yet `ormar` adds its own parameters and has some nuances when working with default values,
 therefore it's listed here for clarity.
 
-`dict` as the name suggests export data from model tree to dictionary.
+`model_dump` as the name suggests export data from model tree to dictionary.
 
-Explanation of dict parameters:
+Explanation of model_dump parameters:
 
 ### include (`ormar` modified)
 
@@ -55,14 +55,14 @@ Note that `pydantic` has an uncommon pattern of including/ excluding fields in l
 And if you want to exclude the field in all children you need to pass a `__all__` key to dictionary. 
 
 You cannot exclude nested models in `Set`s in `pydantic` but you can in `ormar` 
-(by adding double underscore on relation name i.e. to exclude name of category for a book you cen use `exclude={"book__category__name"}`)
+(by adding double underscore on relation name i.e. to exclude name of category for a book you can use `exclude={"book__category__name"}`)
 
 `ormar` does not support by index exclusion/ inclusions and accepts a simplified and more user-friendly notation.
 
 To check how you can include/exclude fields, including nested fields check out [fields](../queries/select-columns.md#fields) section that has an explanation and a lot of samples.
 
 !!!note
-        The fact that in `ormar` you can exclude nested models in sets, you can exclude from a whole model tree in `response_model_exclude` and `response_model_include` in fastapi!
+    The fact that in `ormar` you can exclude nested models in sets, you can exclude from a whole model tree in `response_model_exclude` and `response_model_include` in fastapi!
 
 ### exclude (`ormar` modified)
 
@@ -81,7 +81,7 @@ You cannot exclude nested models in `Set`s in `pydantic` but you can in `ormar`
 To check how you can include/exclude fields, including nested fields check out [fields](../queries/select-columns.md#fields) section that has an explanation and a lot of samples.
 
 !!!note
-        The fact that in `ormar` you can exclude nested models in sets, you can exclude from a whole model tree in `response_model_exclude` and `response_model_include` in fastapi!
+    The fact that in `ormar` you can exclude nested models in sets, you can exclude from a whole model tree in `response_model_exclude` and `response_model_include` in fastapi!
 
 ### exclude_unset
 
@@ -90,9 +90,9 @@ To check how you can include/exclude fields, including nested fields check out [
 Flag indicates whether fields which were not explicitly set when creating the model should be excluded from the returned dictionary.
 
 !!!warning
-        Note that after you save data into database each field has its own value -> either provided by you, default, or `None`.
-        
-        That means that when you load the data from database, **all** fields are set, and this flag basically stop working! 
+    Note that after you save data into database each field has its own value -> either provided by you, default, or `None`.
+    
+    That means that when you load the data from database, **all** fields are set, and this flag basically stop working! 
 
 ```python
 class Category(ormar.Model):
@@ -270,26 +270,26 @@ assert item.model_dump(exclude_through_models=True) == {
                        ]}
 ```
 
-## json
+## model_dump_json()
 
-`json()` has exactly the same parameters as `model_dump()` so check above.
+`model_dump_json()` has exactly the same parameters as `model_dump()` so check above.
 
 Of course the end result is a string with json representation and not a dictionary.
 
-## get_pydantic
+## get_pydantic()
 
 `get_pydantic(include: Union[Set, Dict] = None, exclude: Union[Set, Dict] = None)`
 
 This method allows you to generate `pydantic` models from your ormar models without you needing to retype all the fields.
 
-Note that if you have nested models, it **will generate whole tree of pydantic models for you!**
+Note that if you have nested models, it **will generate whole tree of pydantic models for you!** but in a way that prevents cyclic references issues.
 
 Moreover, you can pass `exclude` and/or `include` parameters to keep only the fields that you want to, including in nested models.
 
 That means that this way you can effortlessly create pydantic models for requests and responses in `fastapi`.
 
 !!!Note
-        To read more about possible excludes/includes and how to structure your exclude dictionary or set visit [fields](../queries/select-columns.md#fields) section of documentation
+    To read more about possible excludes/includes and how to structure your exclude dictionary or set visit [fields](../queries/select-columns.md#fields) section of documentation
 
 Given sample ormar models like follows:
 
@@ -330,8 +330,8 @@ class Category(BaseModel):
 ```
 
 !!!warning
-        Note that it's not a good practice to have several classes with same name in one module, as well as it would break `fastapi` docs.
-        Thats's why ormar adds random 3 uppercase letters to the class name. In example above it means that in reality class would be named i.e. `Category_XIP(BaseModel)`.
+    Note that it's not a good practice to have several classes with same name in one module, as well as it would break `fastapi` docs.
+    Thats's why ormar adds random 3 uppercase letters to the class name. In example above it means that in reality class would be named i.e. `Category_XIP(BaseModel)`.
 
 To exclude or include nested fields you can use dict or double underscores.
 
@@ -351,19 +351,19 @@ class Category(BaseModel):
     items: Optional[List[Item]]
 ```
 
-Of course, you can use also deeply nested structures and ormar will generate it pydantic equivalent you (in a way that exclude loops).
+Of course, you can use also deeply nested structures and ormar will generate it's pydantic equivalent for you (in a way that exclude loops).
 
 Note how `Item` model above does not have a reference to `Category` although in ormar the relation is bidirectional (and `ormar.Item` has `categories` field).
 
 !!!warning
-        Note that the generated pydantic model will inherit all **field** validators from the original `ormar` model, that includes the ormar choices validator as well as validators defined with `pydantic.validator` decorator.
-        
-        But, at the same time all root validators present on `ormar` models will **NOT** be copied to the generated pydantic model. Since root validator can operate on all fields and a user can exclude some fields during generation of pydantic model it's not safe to copy those validators.
-        If required, you need to redefine/ manually copy them to generated pydantic model.
+    Note that the generated pydantic model will inherit all **field** validators from the original `ormar` model, that includes the ormar choices validator as well as validators defined with `pydantic.validator` decorator.
+    
+    But, at the same time all root validators present on `ormar` models will **NOT** be copied to the generated pydantic model. Since root validator can operate on all fields and a user can exclude some fields during generation of pydantic model it's not safe to copy those validators.
+    If required, you need to redefine/ manually copy them to generated pydantic model.
 
-## load
+## load()
 
-By default when you query a table without prefetching related models, the ormar will still construct
+By default, when you query a table without prefetching related models, the ormar will still construct
 your related models, but populate them only with the pk value. You can load the related model by calling `load()` method.
 
 `load()` can also be used to refresh the model from the database (if it was changed by some other process). 
@@ -378,14 +378,14 @@ await track.album.load()
 track.album.name # will return 'Malibu'
 ```
 
-## load_all
+## load_all()
 
 `load_all(follow: bool = False, exclude: Union[List, str, Set, Dict] = None) -> Model`
 
 Method works like `load()` but also goes through all relations of the `Model` on which the method is called, 
 and reloads them from database.
 
-By default the `load_all` method loads only models that are directly related (one step away) to the model on which the method is called.
+By default, the `load_all` method loads only models that are directly related (one step away) to the model on which the method is called.
 
 But you can specify the `follow=True` parameter to traverse through nested models and load all of them in the relation tree.
 
@@ -411,7 +411,7 @@ Method performs one database query so it's more efficient than nested calls to `
 !!!warning
     All relations are cleared on `load_all()`, so if you exclude some nested models they will be empty after call.
 
-## save
+## save()
 
 `save() -> self`
 
@@ -430,7 +430,7 @@ track = await Track.objects.get(name='The Bird')
 await track.save() # will raise integrity error as pk is populated
 ```
 
-## update
+## update()
 
 `update(_columns: List[str] = None, **kwargs) -> self`
 
@@ -449,7 +449,7 @@ To update only selected columns from model into the database provide a list of c
 
 In example:
 
-```python
+```python hl_lines="16"
 class Movie(ormar.Model):
     ormar_config = base_ormar_config.copy()
 
@@ -476,9 +476,9 @@ assert terminator.year == 1984
 ```
 
 !!!warning
-        Note that `update()` does not refresh the instance of the Model, so if you change more columns than you pass in `_columns` list your Model instance will have different values than the database!
+    Note that `update()` does not refresh the instance of the Model, so if you change more columns than you pass in `_columns` list your Model instance will have different values than the database!
 
-## upsert
+## upsert()
 
 `upsert(**kwargs) -> self`
 
@@ -497,7 +497,7 @@ await track.upsert(name='The Bird Strikes Again') # will call update as pk is al
 ```
 
 
-## delete
+## delete()
 
 You can delete models by using `QuerySet.delete()` method or by using your model and calling `delete()` method.
 
@@ -509,7 +509,7 @@ await track.delete() # will delete the model from database
 !!!tip
     Note that that `track` object stays the same, only record in the database is removed.
 
-## save_related
+## save_related()
 
 `save_related(follow: bool = False, save_all: bool = False, exclude=Optional[Union[Set, Dict]]) -> None`
 
@@ -532,11 +532,11 @@ If you want to skip saving some of the relations you can pass `exclude` paramete
 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 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.
+    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 on each branch of relation tree,