Merge branch 'main' into main

Author: tiangolo

docs/release-notes.md

@@ -2,6 +2,9 @@
 
 ## Latest Changes
 
+* ✏ Fix typo in `docs/tutorial/relationship-attributes/define-relationships-attributes.md`. PR [#239](https://github.com/tiangolo/sqlmodel/pull/239) by [@jalvaradosegura](https://github.com/jalvaradosegura).
+* ✏ Fix typo in `docs/tutorial/fastapi/simple-hero-api.md`. PR [#80](https://github.com/tiangolo/sqlmodel/pull/80) by [@joemudryk](https://github.com/joemudryk).
+* ✏ Fix typos in multiple files in the docs. PR [#400](https://github.com/tiangolo/sqlmodel/pull/400) by [@VictorGambarini](https://github.com/VictorGambarini).
 * ✏ Fix typo in `docs/tutorial/code-structure.md`. PR [#344](https://github.com/tiangolo/sqlmodel/pull/344) by [@marciomazza](https://github.com/marciomazza).
 * ✏ Fix typo in `docs/db-to-code.md`. PR [#155](https://github.com/tiangolo/sqlmodel/pull/155) by [@gr8jam](https://github.com/gr8jam).
 * ✏ Fix typo in `docs/contributing.md`. PR [#323](https://github.com/tiangolo/sqlmodel/pull/323) by [@Fardad13](https://github.com/Fardad13).

docs/tutorial/automatic-id-none-refresh.md

@@ -1,6 +1,6 @@
 # Automatic IDs, None Defaults, and Refreshing Data
 
-In the previous chapter we saw how to add rows to the database using **SQLModel**.
+In the previous chapter, we saw how to add rows to the database using **SQLModel**.
 
 Now let's talk a bit about why the `id` field **can't be `NULL`** on the database because it's a **primary key**, and we declare it using `Field(primary_key=True)`.
 
@@ -11,7 +11,7 @@ But the same `id` field actually **can be `None`** in the Python code, so we dec
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:6-10]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -68,7 +68,7 @@ If we ran this code before saving the hero to the database and the `hero_1.id` w
 TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
 ```
 
-But by declaring it with `Optional[int]` the editor will help us to avoid writing broken code by showing us a warning telling us that the code could be invalid if `hero_1.id` is `None`. 🔍
+But by declaring it with `Optional[int]`, the editor will help us to avoid writing broken code by showing us a warning telling us that the code could be invalid if `hero_1.id` is `None`. 🔍
 
 ## Print the Default `id` Values
 
@@ -79,7 +79,7 @@ We can confirm that by printing our heroes before adding them to the database:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-31]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -98,7 +98,7 @@ That will output:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 Before interacting with the database
 Hero 1: id=None name='Deadpond' secret_name='Dive Wilson' age=None
@@ -118,7 +118,7 @@ What happens when we `add` these objects to the **session**?
 
 After we add the `Hero` instance objects to the **session**, the IDs are *still* `None`.
 
-We can verify by creating a session using a `with` block, and adding the objects. And then printing them again:
+We can verify by creating a session using a `with` block and adding the objects. And then printing them again:
 
 ```Python hl_lines="19-21"
 # Code above omitted 👆
@@ -144,7 +144,7 @@ This will, again, output the `id`s of the objects as `None`:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 After adding to the session
 Hero 1: id=None name='Deadpond' secret_name='Dive Wilson' age=None
@@ -165,7 +165,7 @@ Then we can `commit` the changes in the session, and print again:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-48]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -184,7 +184,7 @@ And now, something unexpected happens, look at the output, it seems as if the `H
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 // Here the engine talks to the database, the SQL part
 INFO Engine BEGIN (implicit)

docs/tutorial/fastapi/delete.md

@@ -39,6 +39,6 @@ After deleting it successfully, we just return a response of:
 
 ## Recap
 
-That's it, feel free to try it out in the interactve docs UI to delete some heroes. 💥
+That's it, feel free to try it out in the interactive docs UI to delete some heroes. 💥
 
 Using **FastAPI** to read data and combining it with **SQLModel** makes it quite straightforward to delete data from the database.

docs/tutorial/fastapi/limit-and-offset.md

@@ -2,14 +2,14 @@
 
 When a client sends a request to get all the heroes, we have been returning them all.
 
-But if we had **thousands** of heroes that could consume a lot of **computational resources**, network bandwith, etc.
+But if we had **thousands** of heroes that could consume a lot of **computational resources**, network bandwidth, etc.
 
-So we probably want to limit it.
+So, we probably want to limit it.
 
 Let's use the same **offset** and **limit** we learned about in the previous tutorial chapters for the API.
 
 !!! info
-    In many cases this is also called **pagination**.
+    In many cases, this is also called **pagination**.
 
 ## Add a Limit and Offset to the Query Parameters
 
@@ -38,13 +38,13 @@ And by default, we will return a maximum of `100` heroes, so `limit` will have a
 
 </details>
 
-We want to allow clients to set a different `offset` and `limit` values.
+We want to allow clients to set different `offset` and `limit` values.
 
 But we don't want them to be able to set a `limit` of something like `9999`, that's over `9000`! 😱
 
 So, to prevent it, we add additional validation to the `limit` query parameter, declaring that it has to be **l**ess **t**han or **e**qual to `100` with `lte=100`.
 
-This way, a client can decide to take less heroes if they want, but not more.
+This way, a client can decide to take fewer heroes if they want, but not more.
 
 !!! info
     If you need to refresh how query parameters and their validation work, check out the docs in FastAPI:

docs/tutorial/fastapi/multiple-models.md

@@ -2,15 +2,15 @@
 
 We have been using the same `Hero` model to declare the schema of the data we receive in the API, the table model in the database, and the schema of the data we send back in responses.
 
-But in most of the cases there are slight differences, let's use multiple models to solve it.
+But in most of the cases, there are slight differences. Let's use multiple models to solve it.
 
 Here you will see the main and biggest feature of **SQLModel**. 😎
 
 ## Review Creation Schema
 
 Let's start by reviewing the automatically generated schemas from the docs UI.
 
-For input we have:
+For input, we have:
 
 <img class="shadow" alt="Interactive API docs UI" src="/img/tutorial/fastapi/simple-hero-api/image01.png">
 
@@ -20,7 +20,7 @@ This means that the client could try to use the same ID that already exists in t
 
 That's not what we want.
 
-We want the client to only send the data that is needed to create a new hero:
+We want the client only to send the data that is needed to create a new hero:
 
 * `name`
 * `secret_name`
@@ -63,7 +63,7 @@ The ultimate goal of an API is for some **clients to use it**.
 
 The clients could be a frontend application, a command line program, a graphical user interface, a mobile application, another backend application, etc.
 
-And the code those clients write depend on what our API tells them they **need to send**, and what they can **expect to receive**.
+And the code those clients write depends on what our API tells them they **need to send**, and what they can **expect to receive**.
 
 Making both sides very clear will make it much easier to interact with the API.
 
@@ -164,7 +164,7 @@ Let's first check how is the process to create a hero now:
 
 Let's check that in detail.
 
-Now we use the type annotation `HeroCreate` for the request JSON data, in the `hero` parameter of the **path operation function**.
+Now we use the type annotation `HeroCreate` for the request JSON data in the `hero` parameter of the **path operation function**.
 
 ```Python hl_lines="3"
 # Code above omitted 👆
@@ -180,9 +180,9 @@ The method `.from_orm()` reads data from another object with attributes and crea
 
 The alternative is `Hero.parse_obj()` that reads data from a dictionary.
 
-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.
+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.
 
-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.
+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.
 
 ```Python hl_lines="3"
 # Code above omitted 👆
@@ -192,7 +192,7 @@ With this we create a new `Hero` instance (the one for the database) and put it
 # Code below omitted 👇
 ```
 
-Then we just `add` it to the **session**, `commit`, and `refresh` it, and finally we return the same `db_hero` variable that has the just refreshed `Hero` instance.
+Then we just `add` it to the **session**, `commit`, and `refresh` it, and finally, we return the same `db_hero` variable that has the just refreshed `Hero` instance.
 
 Because it is just refreshed, it has the `id` field set with a new ID taken from the database.
 
@@ -206,30 +206,30 @@ And now that we return it, FastAPI will validate the data with the `response_mod
 # Code below omitted 👇
 ```
 
-This will validate that all the data that we promised is there, and will remove any data we didn't declare.
+This will validate that all the data that we promised is there and will remove any data we didn't declare.
 
 !!! tip
-    This filtering could be very important, and could be a very good security feature, for example to make sure you filter private data, hashed passwords, etc.
+    This filtering could be very important and could be a very good security feature, for example, to make sure you filter private data, hashed passwords, etc.
 
     You can read more about it in the <a href="https://fastapi.tiangolo.com/tutorial/response-model/" class="external-link" target="_blank">FastAPI docs about Response Model</a>.
 
-In particular, it will make sure that the `id` is there, and that it is indeed an integer (and not `None`).
+In particular, it will make sure that the `id` is there and that it is indeed an integer (and not `None`).
 
 ## Shared Fields
 
 But looking closely, we could see that these models have a lot of **duplicated information**.
 
-All **the 3 models** declare that thay share some **common fields** that look exactly the same:
+All **the 3 models** declare that they share some **common fields** that look exactly the same:
 
 * `name`, required
 * `secret_name`, required
 * `age`, optional
 
-And then they declare other fields with some differences (in this case only about the `id`).
+And then they declare other fields with some differences (in this case, only about the `id`).
 
 We want to **avoid duplicated information** if possible.
 
-This is important if, for example, in the future we decide to **refactor the code** and rename one field (column). For example, from `secret_name` to `secret_identity`.
+This is important if, for example, in the future, we decide to **refactor the code** and rename one field (column). For example, from `secret_name` to `secret_identity`.
 
 If we have that duplicated in multiple models, we could easily forget to update one of them. But if we **avoid duplication**, there's only one place that would need updating. ✨
 
@@ -363,7 +363,7 @@ This means that there's nothing else special in this class apart from the fact t
 
 As an alternative, we could use `HeroBase` directly in the API code instead of `HeroCreate`, but it would show up in the automatic docs UI with that name "`HeroBase`" which could be **confusing** for clients. Instead, "`HeroCreate`" is a bit more explicit about what it is for.
 
-On top of that, we could easily decide in the future that we want to receive **more data** when creating a new hero apart from the data in `HeroBase` (for example a password), and now we already have the class to put those extra fields.
+On top of that, we could easily decide in the future that we want to receive **more data** when creating a new hero apart from the data in `HeroBase` (for example, a password), and now we already have the class to put those extra fields.
 
 ### The `HeroRead` **Data Model**
 
@@ -390,7 +390,7 @@ This one just declares that the `id` field is required when reading a hero from
 
 ## Review the Updated Docs UI
 
-The FastAPI code is still the same as above, we still use `Hero`, `HeroCreate`, and `HeroRead`. But now we define them in a smarter way with inheritance.
+The FastAPI code is still the same as above, we still use `Hero`, `HeroCreate`, and `HeroRead`. But now, we define them in a smarter way with inheritance.
 
 So, we can jump to the docs UI right away and see how they look with the updated data.
 
@@ -400,7 +400,7 @@ Let's see the new UI for creating a hero:
 
 <img class="shadow" alt="Interactive API docs UI" src="/img/tutorial/fastapi/multiple-models/image02.png">
 
-Nice! It now shows that to create a hero, we just pass the `name`, `secret_name`, and optinally `age`.
+Nice! It now shows that to create a hero, we just pass the `name`, `secret_name`, and optionally `age`.
 
 We no longer pass an `id`.
 
@@ -416,7 +416,7 @@ And if we check the schema for the **Read Heroes** *path operation* it will also
 
 ## Inheritance and Table Models
 
-We just saw how powerful inheritance of these models can be.
+We just saw how powerful the inheritance of these models could be.
 
 This is a very simple example, and it might look a bit... meh. 😅
 

docs/tutorial/fastapi/read-one.md

@@ -42,7 +42,7 @@ But if the integer is not the ID of any hero in the database, it will not find a
 
 So, we check it in an `if` block, if it's `None`, we raise an `HTTPException` with a `404` status code.
 
-And to use it we first import `HTTPException` from `fastapi`.
+And to use it, we first import `HTTPException` from `fastapi`.
 
 This will let the client know that they probably made a mistake on their side and requested a hero that doesn't exist in the database.
 

docs/tutorial/fastapi/relationships.md

@@ -102,7 +102,7 @@ In this case, we used `response_model=TeamRead` and `response_model=HeroRead`, s
 
 Now let's stop for a second and think about it.
 
-We cannot simply include *all* the data including all the internal relationships, because each **hero** has an attribute `team` with their team, and then that **team** also has an attribute `heroes` with all the **heroes** in the team, including this one.
+We cannot simply include *all* the data, including all the internal relationships, because each **hero** has an attribute `team` with their team, and then that **team** also has an attribute `heroes` with all the **heroes** in the team, including this one.
 
 If we tried to include everything, we could make the server application **crash** trying to extract **infinite data**, going through the same hero and team over and over again internally, something like this:
 
@@ -152,7 +152,7 @@ If we tried to include everything, we could make the server application **crash*
 }
 ```
 
-As you can see, in this example we would get the hero **Rusty-Man**, and from this hero we would get the team **Preventers**, and then from this team we would get its heroes, of course, including **Rusty-Man**... 😱
+As you can see, in this example, we would get the hero **Rusty-Man**, and from this hero we would get the team **Preventers**, and then from this team we would get its heroes, of course, including **Rusty-Man**... 😱
 
 So we start again, and in the end, the server would just crash trying to get all the data with a `"Maximum recursion error"`, we would not even get a response like the one above.
 
@@ -164,7 +164,7 @@ This is a decision that will depend on **each application**.
 
 In our case, let's say that if we get a **list of heroes**, we don't want to also include each of their teams in each one.
 
-And if we get a **list of teams**, we don't want to get a a list of the heroes for each one.
+And if we get a **list of teams**, we don't want to get a list of the heroes for each one.
 
 But if we get a **single hero**, we want to include the team data (without the team's heroes).
 
@@ -195,15 +195,15 @@ We'll add them **after** the other models so that we can easily reference the pr
 
 </details>
 
-These two models are very **simple in code**, but there's a lot happening here, let's check it out.
+These two models are very **simple in code**, but there's a lot happening here. Let's check it out.
 
 ### Inheritance and Type Annotations
 
 The `HeroReadWithTeam` **inherits** from `HeroRead`, which means that it will have the **normal fields for reading**, including the required `id` that was declared in `HeroRead`.
 
 And then it adds the **new field** `team`, which could be `None`, and is declared with the type `TeamRead` with the base fields for reading a team.
 
-Then we do the same for the `TeamReadWithHeroes`, it **inherits** from `TeamRead`, and declare the **new field** `heroes` which is a list of `HeroRead`.
+Then we do the same for the `TeamReadWithHeroes`, it **inherits** from `TeamRead`, and declares the **new field** `heroes`, which is a list of `HeroRead`.
 
 ### Data Models Without Relationship Attributes
 
@@ -213,7 +213,7 @@ Instead, here these are only **data models** that will tell FastAPI **which attr
 
 ### Reference to Other Models
 
-Also notice that the field `team` is not declared with this new `TeamReadWithHeroes`, because that would again create that infinite recursion of data. Instead, we declare it with the normal `TeamRead` model.
+Also, notice that the field `team` is not declared with this new `TeamReadWithHeroes`, because that would again create that infinite recursion of data. Instead, we declare it with the normal `TeamRead` model.
 
 And the same for `TeamReadWithHeroes`, the model used for the new field `heroes` uses `HeroRead` to get only each hero's data.
 
@@ -326,12 +326,12 @@ Now we get the list of **heroes** included:
 
 ## Recap
 
-Using the same techniques to declare additonal **data models** we can tell FastAPI what data to return in the responses, even when we return **table models**.
+Using the same techniques to declare additional **data models**, we can tell FastAPI what data to return in the responses, even when we return **table models**.
 
 Here we almost **didn't have to change the FastAPI app** code, but of course, there will be cases where you need to get the data and process it in different ways in the *path operation function* before returning it.
 
 But even in those cases, you will be able to define the **data models** to use in `response_model` to tell FastAPI how to validate and filter the data.
 
 By this point, you already have a very robust API to handle data in a SQL database combining **SQLModel** with **FastAPI**, and implementing **best practices**, like data validation, conversion, filtering, and documentation. ✨
 
-In the next chapter I'll tell you how to implement automated **testing** for your application using FastAPI and SQLModel. ✅
+In the next chapter, I'll tell you how to implement automated **testing** for your application using FastAPI and SQLModel. ✅

docs/tutorial/fastapi/response-model.md

@@ -22,7 +22,7 @@ You can see that there's a possible "Successful Response" with a code `200`, but
 
 <img class="shadow" alt="API docs UI without response data schemas" src="/img/tutorial/fastapi/response-model/image01.png">
 
-Right now we only tell FastAPI the data we want to receive, but we don't tell it yet the data we want to send back.
+Right now, we only tell FastAPI the data we want to receive, but we don't tell it yet the data we want to send back.
 
 Let's do that now. 🤓