You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/tutorial/fastapi/multiple-models.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -175,15 +175,17 @@ Now we use the type annotation `HeroCreate` for the request JSON data in the `he
175
175
# Code below omitted 👇
176
176
```
177
177
178
-
Then we create a new `Hero` (this is the actual **table** model that saves things to the database) using `Hero.from_orm()`.
178
+
Then we create a new `Hero` (this is the actual **table** model that saves things to the database) using `Hero.model_validate()`.
179
179
180
-
The method `.from_orm()` reads data from another object with attributes and creates a new instance of this class, in this case `Hero`.
180
+
The method `.model_validate()` reads data from another object with attributes (or a dict) and creates a new instance of this class, in this case `Hero`.
181
181
182
-
The alternative is `Hero.parse_obj()`that reads data from a dictionary.
182
+
In this case, we have a `HeroCreate` instance in the `hero` variable. This is an object with attributes, so we use `.model_validate()`to read those attributes.
183
183
184
-
But as in this case, we have a `HeroCreate` instance in the `hero` variable. This is an object with attributes, so we use `.from_orm()` to read those attributes.
184
+
/// tip
185
+
In versions of **SQLModel** before `0.0.14` you would use the method `.from_orm()`, but it is now deprecated and you should use `.model_validate()` instead.
186
+
///
185
187
186
-
With this, we create a new `Hero` instance (the one for the database) and put it in the variable `db_hero` from the data in the `hero` variable that is the `HeroCreate` instance we received from the request.
188
+
We can now create a new `Hero` instance (the one for the database) and put it in the variable `db_hero` from the data in the `hero` variable that is the `HeroCreate` instance we received from the request.
Copy file name to clipboardExpand all lines: docs/tutorial/fastapi/update.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -90,7 +90,7 @@ So, we need to read the hero from the database, with the **same logic** we used
90
90
91
91
The `HeroUpdate` model has all the fields with **default values**, because they all have defaults, they are all optional, which is what we want.
92
92
93
-
But that also means that if we just call `hero.dict()` we will get a dictionary that could potentially have several or all of those values with their defaults, for example:
93
+
But that also means that if we just call `hero.model_dump()` we will get a dictionary that could potentially have several or all of those values with their defaults, for example:
94
94
95
95
```Python
96
96
{
@@ -102,7 +102,7 @@ But that also means that if we just call `hero.dict()` we will get a dictionary
102
102
103
103
And then, if we update the hero in the database with this data, we would be removing any existing values, and that's probably **not what the client intended**.
104
104
105
-
But fortunately Pydantic models (and so SQLModel models) have a parameter we can pass to the `.dict()` method for that: `exclude_unset=True`.
105
+
But fortunately Pydantic models (and so SQLModel models) have a parameter we can pass to the `.model_dump()` method for that: `exclude_unset=True`.
106
106
107
107
This tells Pydantic to **not include** the values that were **not sent** by the client. Saying it another way, it would **only** include the values that were **sent by the client**.
108
108
@@ -112,7 +112,7 @@ So, if the client sent a JSON with no values:
112
112
{}
113
113
```
114
114
115
-
Then the dictionary we would get in Python using `hero.dict(exclude_unset=True)` would be:
115
+
Then the dictionary we would get in Python using `hero.model_dump(exclude_unset=True)` would be:
116
116
117
117
```Python
118
118
{}
@@ -126,7 +126,7 @@ But if the client sent a JSON with:
126
126
}
127
127
```
128
128
129
-
Then the dictionary we would get in Python using `hero.dict(exclude_unset=True)` would be:
129
+
Then the dictionary we would get in Python using `hero.model_dump(exclude_unset=True)` would be:
130
130
131
131
```Python
132
132
{
@@ -152,6 +152,9 @@ Then we use that to get the data that was actually sent by the client:
152
152
153
153
///
154
154
155
+
/// tip
156
+
Before SQLModel 0.0.14, the method was called `hero.dict(exclude_unset=True)`, but it was renamed to `hero.model_dump(exclude_unset=True)` to be consistent with Pydantic v2.
157
+
155
158
## Update the Hero in the Database
156
159
157
160
Now that we have a **dictionary with the data sent by the client**, we can iterate for each one of the keys and the values, and then we set them in the database hero model `db_hero` using `setattr()`.
@@ -208,7 +211,7 @@ So, if the client wanted to intentionally remove the `age` of a hero, they could
208
211
}
209
212
```
210
213
211
-
And when getting the data with `hero.dict(exclude_unset=True)`, we would get:
214
+
And when getting the data with `hero.model_dump(exclude_unset=True)`, we would get:
212
215
213
216
```Python
214
217
{
@@ -226,4 +229,4 @@ These are some of the advantages of Pydantic, that we can use with SQLModel.
226
229
227
230
## Recap
228
231
229
-
Using `.dict(exclude_unset=True)` in SQLModel models (and Pydantic models) we can easily update data **correctly**, even in the **edge cases**. 😎
232
+
Using `.model_dump(exclude_unset=True)` in SQLModel models (and Pydantic models) we can easily update data **correctly**, even in the **edge cases**. 😎
0 commit comments