mirror of
https://github.com/fastapi/sqlmodel.git
synced 2026-01-05 00:51:07 -06:00
🔧 Update config with new pymdown extensions (#712)
* 🔧 Update config with new pymdown extensions * 📝 Update admonition blocks syntax * 📝 Update syntax for tabs with new pymdown extensions
This commit is contained in:
committed by
GitHub
parent
71baff6015
commit
a95bd3873d
@@ -79,12 +79,15 @@ You can try that out in **DB Browser for SQLite**:
|
||||
|
||||
<img class="shadow" src="/img/tutorial/select/image01.png">
|
||||
|
||||
!!! warning
|
||||
Here we are getting all the rows.
|
||||
/// warning
|
||||
|
||||
If you have thousands of rows, that could be expensive to compute for the database.
|
||||
Here we are getting all the rows.
|
||||
|
||||
You would normally want to filter the rows to receive only the ones you want. But we'll learn about that later in the next chapter.
|
||||
If you have thousands of rows, that could be expensive to compute for the database.
|
||||
|
||||
You would normally want to filter the rows to receive only the ones you want. But we'll learn about that later in the next chapter.
|
||||
|
||||
///
|
||||
|
||||
### A SQL Shortcut
|
||||
|
||||
@@ -240,10 +243,13 @@ We pass the class model `Hero` to the `select()` function. And that tells it tha
|
||||
|
||||
And notice that in the `select()` function we don't explicitly specify the `FROM` part. It is already obvious to **SQLModel** (actually to SQLAlchemy) that we want to select `FROM` the table `hero`, because that's the one associated with the `Hero` class model.
|
||||
|
||||
!!! tip
|
||||
The value of the `statement` returned by `select()` is a special object that allows us to do other things.
|
||||
/// tip
|
||||
|
||||
I'll tell you about that in the next chapters.
|
||||
The value of the `statement` returned by `select()` is a special object that allows us to do other things.
|
||||
|
||||
I'll tell you about that in the next chapters.
|
||||
|
||||
///
|
||||
|
||||
## Execute the Statement
|
||||
|
||||
@@ -360,8 +366,11 @@ Let's review the code up to this point:
|
||||
|
||||
{!./docs_src/tutorial/select/annotations/en/tutorial002.md!}
|
||||
|
||||
!!! tip
|
||||
Check out the number bubbles to see what is done by each line of code.
|
||||
/// tip
|
||||
|
||||
Check out the number bubbles to see what is done by each line of code.
|
||||
|
||||
///
|
||||
|
||||
Here it starts to become more evident why we should have a single **engine** for the whole application, but different **sessions** for each group of operations.
|
||||
|
||||
@@ -373,10 +382,13 @@ And the second section reading data from the database could be in another functi
|
||||
|
||||
So, both sections could be in **different places** and would need their own sessions.
|
||||
|
||||
!!! info
|
||||
To be fair, in this example all that code could actually share the same **session**, there's actually no need to have two here.
|
||||
/// info
|
||||
|
||||
But it allows me to show you how they could be separated and to reinforce the idea that you should have **one engine** per application, and **multiple sessions**, one per each group of operations.
|
||||
To be fair, in this example all that code could actually share the same **session**, there's actually no need to have two here.
|
||||
|
||||
But it allows me to show you how they could be separated and to reinforce the idea that you should have **one engine** per application, and **multiple sessions**, one per each group of operations.
|
||||
|
||||
///
|
||||
|
||||
## Get a List of `Hero` Objects
|
||||
|
||||
@@ -415,8 +427,11 @@ After printing it, we would see something like:
|
||||
]
|
||||
```
|
||||
|
||||
!!! info
|
||||
It would actually look more compact, I'm formatting it a bit for you to see that it is actually a list with all the data.
|
||||
/// info
|
||||
|
||||
It would actually look more compact, I'm formatting it a bit for you to see that it is actually a list with all the data.
|
||||
|
||||
///
|
||||
|
||||
## Compact Version
|
||||
|
||||
@@ -461,8 +476,11 @@ SQLAchemy also has it's own `select`, and SQLModel's `select` uses SQLAlchemy's
|
||||
|
||||
But SQLModel's version does a lot of **tricks** with type annotations to make sure you get the best **editor support** possible, no matter if you use **VS Code**, **PyCharm**, or something else. ✨
|
||||
|
||||
!!! info
|
||||
There was a lot of work and research, with different versions of the internal code, to improve this as much as possible. 🤓
|
||||
/// info
|
||||
|
||||
There was a lot of work and research, with different versions of the internal code, to improve this as much as possible. 🤓
|
||||
|
||||
///
|
||||
|
||||
### SQLModel's `session.exec`
|
||||
|
||||
@@ -492,10 +510,13 @@ On top of that, **SQLModel**'s `session.exec()` also does some tricks to reduce
|
||||
|
||||
But SQLModel's `Session` still has access to `session.execute()` too.
|
||||
|
||||
!!! tip
|
||||
Your editor will give you autocompletion for both `session.exec()` and `session.execute()`.
|
||||
/// tip
|
||||
|
||||
📢 Remember to **always use `session.exec()`** to get the best editor support and developer experience.
|
||||
Your editor will give you autocompletion for both `session.exec()` and `session.execute()`.
|
||||
|
||||
📢 Remember to **always use `session.exec()`** to get the best editor support and developer experience.
|
||||
|
||||
///
|
||||
|
||||
### Caveats of **SQLModel** Flavor
|
||||
|
||||
|
||||
Reference in New Issue
Block a user