python/sqlmodel
1
0
Fork 0
mirror of https://github.com/fastapi/sqlmodel.git synced 2025-12-16 01:59:03 +08:00
Code Issues Packages Projects Releases Wiki Activity

🍱 Update SVG files, a single file per diagram, sans-serif fonts (#1373)

Browse Source 
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
This commit is contained in:
Sebastián Ramírez
2025-05-11 19:13:38 +02:00
committed by GitHub
parent cd19d606ab
commit e7b970cfa8
77 changed files with 14639 additions and 2815 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/tutorial/connect/create-connected-rows.md
View File

@@ -35,7 +35,7 @@ And after we finish working with the data in this chapter, the `hero` table will
Each row in the table `hero` will point to a row in the table `team`:
<img alt="table relationships" src="/img/tutorial/relationships/select/relationships2.svg">
<img alt="table relationships" src="/img/tutorial/relationships/select/relationships2.drawio.svg">
/// info

2
docs/tutorial/connect/create-connected-tables.md
View File

@@ -39,7 +39,7 @@ To connect them, we will add another column to the hero table to point to each t
This way each row in the table `hero` can point to a row in the table `team`:
<img alt="table relationships" src="/img/databases/relationships.svg">
<img alt="table relationships" src="/img/databases/relationships.drawio.svg">
## One-to-Many and Many-to-One

4
docs/tutorial/connect/read-connected-data.md
View File

@@ -293,7 +293,7 @@ And then you tell the database `ON` which condition it should join those two tab
But by default, only the rows from both left and right that match the condition will be returned.
<img alt="table relationships" src="/img/databases/relationships.svg">
<img alt="table relationships" src="/img/databases/relationships.drawio.svg">
In this example of tables above 👆, it would return all the heroes, because every hero has a `team_id`, so every hero can be joined with the `team` table:
@@ -318,7 +318,7 @@ But in the database that we are working with in the code above, **Spider-Boy** d
So there's no way to join the **Spider-Boy** row with some row in the `team` table:
<img alt="table relationships" src="/img/tutorial/relationships/select/relationships2.svg">
<img alt="table relationships" src="/img/tutorial/relationships/select/relationships2.drawio.svg">
Running the same SQL we used above, the resulting table would not include **Spider-Boy** 😱:

18
docs/tutorial/indexes.md
View File

@@ -34,35 +34,35 @@ Imagine a **dictionary**, a book with definitions of words. 📔 ...not a Python
Let's say that you want to **find a word**, for example the word "**database**". You take the dictionary, and open it somewhere, for example in the middle. Maybe you see some definitions of words that start with `m`, like `manual`, so you conclude that you are in the letter `m` in the dictionary.
<img src="/img/tutorial/indexes/dictionary001.svg">
<img src="/img/tutorial/indexes/dictionary001.drawio.svg">
You know that in the alphabet, the letter `d` for `database` comes **before** the letter `m` for `manual`.
<img src="/img/tutorial/indexes/dictionary002.svg">
<img src="/img/tutorial/indexes/dictionary002.drawio.svg">
So, you know you have to search in the dictionary **before** the point you currently are. You still don't know where the word `database` is, because you don't know exactly where the letter `d` is in the dictionary, but you know that **it is not after** that point, you can now **discard the right half** of the dictionary in your search.
<img src="/img/tutorial/indexes/dictionary003.svg">
<img src="/img/tutorial/indexes/dictionary003.drawio.svg">
Next, you **open the dictionary again**, but only taking into account the **half of the dictionary** that can contain the word you want, the **left part of the dictionary**. You open it in the middle of that left part and now you arrive maybe at the letter `f`.
<img src="/img/tutorial/indexes/dictionary004.svg">
<img src="/img/tutorial/indexes/dictionary004.drawio.svg">
You know that `d` from `database` comes before `f`. So it has to be **before** that. But now you know that `database` **is not after** that point, and you can discard the dictionary from that point onward.
<img src="/img/tutorial/indexes/dictionary005.svg">
<img src="/img/tutorial/indexes/dictionary005.drawio.svg">
Now you have a **small section of dictionary** to search (only a **quarter** of dictionary can have your word). You take that **quarter** of the pages at the start of the dictionary that can contain your word, and open it in the middle of that section. Maybe you arrive at the letter `c`.
<img src="/img/tutorial/indexes/dictionary006.svg">
<img src="/img/tutorial/indexes/dictionary005.drawio.svg">
You know the word `database` has to be **after** that and **not before** that point, so you can discard the left part of that block of pages.
<img src="/img/tutorial/indexes/dictionary007.svg">
<img src="/img/tutorial/indexes/dictionary007.drawio.svg">
You repeat this process **a few more times**, and you finally arrive at the letter `d`, you continue with the same process in that section for the letter `d` and you finally **find the word** `database`. 🎉
<img src="/img/tutorial/indexes/dictionary008.svg">
<img src="/img/tutorial/indexes/dictionary008.drawio.svg">
You had to open the dictionary a few times, maybe **5 or 10**. That's actually **very little work** compared to what it could have been.
@@ -96,7 +96,7 @@ Open the index, and after **5 or 10 steps**, quickly find the topic "**database*
Now you know that you need to find "**page 253**". But by looking at the closed book you still don't know where that page is, so you have to **find that page**. To find it, you can do the same process again, but this time, instead of searching for a **topic** in the **index**, you are searching for a **page number** in the **entire book**. And after **5 or 10 more steps**, you find the page 253 in Chapter 5.
<img src="/img/tutorial/indexes/techbook001.svg">
<img src="/img/tutorial/indexes/techbook001.drawio.svg">
After this, even though this book is not a dictionary and has some particular content, you were able to **find the section** in the book that talks about a "**database**" in a **few steps** (say 10 or 20, instead of reading all the 500 pages).

8
docs/tutorial/limit-and-offset.md
View File

@@ -6,7 +6,7 @@ And you also know how to get multiple rows while filtering them using `.where()`
Now let's see how to get only a **range of results**.
<img class="shadow" alt="table with first 3 rows selected" src="/img/tutorial/offset-and-limit/limit.svg">
<img class="shadow" alt="table with first 3 rows selected" src="/img/tutorial/offset-and-limit/limit.drawio.svg">
## Create Data
@@ -34,7 +34,7 @@ The special **select** object we get from `select()` also has a method `.limit()
In this case, instead of getting all the 7 rows, we are limiting them to only get the first 3.
<img class="shadow" alt="table with first 3 rows selected" src="/img/tutorial/offset-and-limit/limit.svg">
<img class="shadow" alt="table with first 3 rows selected" src="/img/tutorial/offset-and-limit/limit.drawio.svg">
## Run the Program on the Command Line
@@ -87,7 +87,7 @@ And then you can interact with the user interface to get the next page, and so o
How do we get the next 3?
<img class="shadow" alt="table with next rows selected, from 4 to 6" src="/img/tutorial/offset-and-limit/limit2.svg">
<img class="shadow" alt="table with next rows selected, from 4 to 6" src="/img/tutorial/offset-and-limit/limit2.drawio.svg">
We can use `.offset()`:
@@ -134,7 +134,7 @@ Then to get the next batch of 3 rows we would offset all the ones we already saw
The database right now has **only 7 rows**, so this query can only get 1 row.
<img class="shadow" alt="table with the last row (7th) selected" src="/img/tutorial/offset-and-limit/limit3.svg">
<img class="shadow" alt="table with the last row (7th) selected" src="/img/tutorial/offset-and-limit/limit3.drawio.svg">
But don't worry, the database won't throw an error trying to get 3 rows when there's only one (as would happen with a Python list).

2
docs/tutorial/many-to-many/create-data.md
View File

@@ -4,7 +4,7 @@ Let's continue from where we left and create some data.
We'll create data for this same **many-to-many** relationship with a link table:
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.svg">
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.drawio.svg">
We'll continue from where we left off with the previous code.

2
docs/tutorial/many-to-many/create-models-with-link.md
View File

@@ -2,7 +2,7 @@
We'll now support **many-to-many** relationships using a **link table** like this:
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.svg">
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.drawio.svg">
Let's start by defining the class models, including the **link table** model.

4
docs/tutorial/many-to-many/index.md
View File

@@ -57,7 +57,7 @@ We have a column in the `hero` table for the `team_id` that points to the ID of
This is how we connect each `hero` with a `team`:
<img alt="table relationships" src="/img/databases/relationships.svg">
<img alt="table relationships" src="/img/databases/relationships.drawio.svg">
Notice that each hero can only have **one** connection. But each team can receive **many** connections. In particular, the team **Preventers** has two heroes.
@@ -83,7 +83,7 @@ As this will represent the **hero-team-link**, let's call the table `heroteamlin
It would look like this:
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.svg">
<img alt="many-to-many table relationships" src="/img/tutorial/many-to-many/many-to-many.drawio.svg">
Notice that now the table `hero` **doesn't have a `team_id`** column anymore, it is replaced by this link table.

6
docs/tutorial/relationship-attributes/back-populates.md
View File

@@ -10,7 +10,7 @@ So, what is that `back_populates` argument in each `Relationship()`?
The value is a string with the name of the attribute in the **other** model class.
<img src="/img/tutorial/relationships/attributes/back-populates.svg">
<img src="/img/tutorial/relationships/attributes/back-populates.drawio.svg">
That tells **SQLModel** that if something changes in this model, it should change that attribute in the other model, and it will work even before committing with the session (that would force a refresh of the data).
@@ -175,7 +175,7 @@ It's quite simple code, it's just a string, but it might be confusing to think e
The string in `back_populates` is the name of the attribute *in the other* model, that will reference *the current* model.
<img src="/img/tutorial/relationships/attributes/back-populates.svg">
<img src="/img/tutorial/relationships/attributes/back-populates.drawio.svg">
So, in the class `Team`, we have an attribute `heroes` and we declare it with `Relationship(back_populates="team")`.
@@ -210,6 +210,6 @@ So, if you are in the class `Hero`, the value of `back_populates` for any relati
So, `back_populates` would most probably be something like `"hero"` or `"heroes"`.
<img src="/img/tutorial/relationships/attributes/back-populates2.svg">
<img src="/img/tutorial/relationships/attributes/back-populates2.drawio.svg">
{* ./docs_src/tutorial/relationship_attributes/back_populates/tutorial003_py310.py ln[27:39] hl[27,34,37,39] *}