✏ Fix typos in docs/tutorial/code-structure.md
, docs/tutorial/fastapi/multiple-models.md
, docs/tutorial/fastapi/simple-hero-api.md
, docs/tutorial/many-to-many/index.md
(#116)
Co-authored-by: moonso <mans.magnusson@scilifelab.se> Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>
This commit is contained in:
parent
13544c0f44
commit
6f1ffccd4f
@ -170,7 +170,7 @@ Let's assume that now the file structure is:
|
||||
|
||||
The problem with circular imports is that Python can't resolve them at <abbr title="While it is executing the program, as oposed to the code as just text in a file stored on disk.">*runtime*</abbr>.
|
||||
|
||||
but when using Python **type annotations** it's very common to need to declare the type of some variables with classes imported from other files.
|
||||
But when using Python **type annotations** it's very common to need to declare the type of some variables with classes imported from other files.
|
||||
|
||||
And the files with those classes might **also need to import** more things from the first files.
|
||||
|
||||
|
@ -361,7 +361,7 @@ And because we can't leave the empty space when creating a new class, but we don
|
||||
|
||||
This means that there's nothing else special in this class apart from the fact that it is named `HeroCreate` and that it inherits from `HeroBase`.
|
||||
|
||||
As an alternative, we could use `HeroBase` directly in the API code instead of `HeroCreate`, but it would show up in the auomatic docs UI with that name "`HeroBase`" which could be **confusing** for clients. Instead, "`HeroCreate`" is a bit more explicit about what it is for.
|
||||
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.
|
||||
|
||||
|
@ -60,7 +60,7 @@ Notice that each hero can only have **one** connection. But each team can receiv
|
||||
|
||||
## Introduce Many-to-Many
|
||||
|
||||
But let's say that as **Deadpond** is a great chracter, they recruit him to the new **Preventers** team, but he's still part of the **Z-Force** team too.
|
||||
But let's say that as **Deadpond** is a great character, they recruit him to the new **Preventers** team, but he's still part of the **Z-Force** team too.
|
||||
|
||||
So, now, we need to be able to have a hero that is connected to **many** teams. And then, each team, should still be able to receive **many** heroes. So we need a **Many-to-Many** relationship.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user