{!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-26]!}
-# Code below ommitted 👇
+# Code below omitted 👇
```
<details>
{!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-41]!}
-# Code below ommitted 👇
+# Code below omitted 👇
```
<details>
{!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-58]!}
-# Code below ommitted 👇
+# Code below omitted 👇
```
<details>
```console
$ python app.py
-// Output above ommitted 👆
+// Output above omitted 👆
// After committing, the objects are expired and have no values
After committing the session
{!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-67]!}
-# Code below ommitted 👇
+# Code below omitted 👇
```
<details>
```console
$ python app.py
-// Output above ommitted 👆
+// Output above omitted 👆
// The first refresh
INFO Engine SELECT hero.id, hero.name, hero.secret_name, hero.age
```console
$ python app.py
-// Output above ommitted 👆
+// Output above omitted 👆
// By finishing the with block, the Session is closed, including a rollback of any pending transaction that could have been there and was not committed
INFO Engine ROLLBACK
### Circular Imports and Type Annotations
-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>.
+The problem with circular imports is that Python can't resolve them at <abbr title="While it is executing the program, as opposed 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.
Most of that should look familiar:
-The column will be named `team_id`. It will be an integer, and it could be `NULL` in the database (or `None` in Python), becase there could be some heroes that don't belong to any team.
+The column will be named `team_id`. It will be an integer, and it could be `NULL` in the database (or `None` in Python), because there could be some heroes that don't belong to any team.
We add a default of `None` to the `Field()` so we don't have to explicitly pass `team_id=None` when creating a hero.
We saw how to interact with SQLite databases in files using **DB Browser for SQLite** in a visual user interface.
-We also saw how to use it to write some SQL directly to the SQLite database. This will be useful to verify the data in the database is looking correclty, to debug, etc.
+We also saw how to use it to write some SQL directly to the SQLite database. This will be useful to verify the data in the database is looking correctly, to debug, etc.
In the next chapters we will start using **SQLModel** to interact with the database, and we will continue to use **DB Browser for SQLite** at the same time to look at the database underneath. 🔍
This test looks fine, but there's a problem.
-If we run it, it will use the same **production database** that we are using to store our very important **heroes**, and we will end up adding unnecesary data to it, or even worse, in future tests we could end up removing production data.
+If we run it, it will use the same **production database** that we are using to store our very important **heroes**, and we will end up adding unnecessary data to it, or even worse, in future tests we could end up removing production data.
So, we should use an independent **testing database**, just for the tests.
// Remember that you might need to use python3.9 or similar 💡
// Create the virtual environment using the module "venv"
$ python3 -m venv env
- // ...here it creates the virtual enviroment in the directory "env"
+ // ...here it creates the virtual environment in the directory "env"
// Activate the virtual environment
$ source ./env/bin/activate
// Verify that the virtual environment is active
```console
// Create the virtual environment using the module "venv"
# >$ python3 -m venv env
- // ...here it creates the virtual enviroment in the directory "env"
+ // ...here it creates the virtual environment in the directory "env"
// Activate the virtual environment
# >$ .\env\Scripts\Activate.ps1
// Verify that the virtual environment is active
```Python hl_lines="3"
{!./docs_src/tutorial/insert/tutorial001.py[ln:1-3]!}
-# Code below ommitted 👇
+# Code below omitted 👇
```
<details>
## Recap
-After setting up the model link, using it with **relationship attributes** is fairly straighforward, just Python objects. ✨
+After setting up the model link, using it with **relationship attributes** is fairly straightforward, just Python objects. ✨
## Continue From Previous Code
-We'll continue with the same examples we have been using in the previous chapters to create and select data and we'll keep udpating them.
+We'll continue with the same examples we have been using in the previous chapters to create and select data and we'll keep updating them.
<details>
<summary>👀 Full file preview</summary>
</details>
-The first important thing is, we *haven't commited* the hero yet, so accessing the list of heroes would not trigger an automatic refresh.
+The first important thing is, we *haven't committed* the hero yet, so accessing the list of heroes would not trigger an automatic refresh.
But in our code, in this exact point in time, we already said that **Spider-Boy** is no longer part of the **Preventers**. 🔥
## Get Relationship Team - New Way
-But now that we have the **relationship attributes**, we can just access them, and **SQLModel** (actually SQLAlchemy) will go and fetch the correspoinding data from the database, and make it available in the attribute. ✨
+But now that we have the **relationship attributes**, we can just access them, and **SQLModel** (actually SQLAlchemy) will go and fetch the corresponding data from the database, and make it available in the attribute. ✨
So, the highlighted block above, has the same results as the block below:
```Python hl_lines="3"
{!./docs_src/tutorial/select/tutorial001.py[ln:1-3]!}
-# More code below ommitted 👇
+# More code below omitted 👇
```
<details>
If you see SQLAlchemy tutorials, they will always use `session.execute()`.
-**SQLModel**'s own `Session` inherits directly from SQLAlchemy's `Session`, and adds this additonal method `session.exec()`. Underneath, it uses the same `session.execute()`.
+**SQLModel**'s own `Session` inherits directly from SQLAlchemy's `Session`, and adds this additional method `session.exec()`. Underneath, it uses the same `session.execute()`.
But `session.exec()` does several **tricks** combined with the tricks in `session()` to give you the **best editor support**, with **autocompletion** and **inline errors** everywhere, even after getting data from a select. ✨
## Filter Rows Using `WHERE` with **SQLModel**
-Now, the same way that we add `WHERE` to a SQL statement to filter rows, we can add a `.where()` to a **SQLModel** `select()` statment to filter rows, which will filter the objects returned:
+Now, the same way that we add `WHERE` to a SQL statement to filter rows, we can add a `.where()` to a **SQLModel** `select()` statement to filter rows, which will filter the objects returned:
```Python hl_lines="5"
# Code above omitted 👆
WHERE hero.age >= ? AND hero.age < ?
INFO Engine [no key 0.00014s] (35, 40)
-// The two heros printed
+// The two heroes printed
age=35 id=5 name='Black Lion' secret_name='Trevor Challa'
age=36 id=6 name='Dr. Weird' secret_name='Steve Weird'
Hero 3:
```
-21. Print the line `"After commiting the session, show IDs"`.
+21. Print the line `"After committing the session, show IDs"`.
Generates the output:
!!! tip
SQLAlchemy is still using the previous transaction, so it doesn't have to create a new one.
-18. Print the first hero, now udpated.
+18. Print the first hero, now updated.
This generates the output:
You shouldn't use this class directly.
It's used internally to recognize when a default value has been overwritten, even
- if the overriden default value was truthy.
+ if the overridden default value was truthy.
"""
def __init__(self, value: Any):
You shouldn't use this function directly.
It's used internally to recognize when a default value has been overwritten, even
- if the overriden default value was truthy.
+ if the overridden default value was truthy.
"""
return _DefaultPlaceholder(value) # type: ignore
def test_validation(clear_sqlmodel):
- """Test validation of implicit and explict None values.
+ """Test validation of implicit and explicit None values.
# For consistency with pydantic, validators are not to be called on
# arguments that are not explicitly provided.
projects / thirdparty / fastapi / sqlmodel.git / commitdiff
