]> git.ipfire.org Git - thirdparty/fastapi/sqlmodel.git/commitdiff
📝 Update docs (#1003)
authorAlejandra <90076947+alejsdev@users.noreply.github.com>
Wed, 17 Jul 2024 03:03:52 +0000 (22:03 -0500)
committerGitHub <noreply@github.com>
Wed, 17 Jul 2024 03:03:52 +0000 (22:03 -0500)
docs/tutorial/automatic-id-none-refresh.md
docs/tutorial/create-db-and-table.md
docs/tutorial/relationship-attributes/create-and-update-relationships.md
docs/tutorial/where.md

index 1f98a76cfe41147c7c17aca94e7b0ac1c748807e..19634923594d10017b90475e6c1fb35dc31d1da2 100644 (file)
@@ -4,7 +4,7 @@ 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)`.
 
-But the same `id` field actually **can be `None`** in the Python code, so we declare the type with `Optional[int]`, and set the default value to `Field(default=None)`:
+But the same `id` field actually **can be `None`** in the Python code, so we declare the type with `int | None (or Optional[int])`, and set the default value to `Field(default=None)`:
 
 //// tab | Python 3.10+
 
index 761c979e0270decb566cae226a7d394abc1b2263..de820ab7607f72cf1360961c3df7a526570e2623 100644 (file)
@@ -145,7 +145,7 @@ Let's now see with more detail these field/column declarations.
 
 ### Optional Fields, Nullable Columns
 
-Let's start with `age`, notice that it has a type of `Optional[int]`.
+Let's start with `age`, notice that it has a type of `int | None (or Optional[int])`.
 
 And we import that `Optional` from the `typing` standard module.
 
index 8b34f0cb53bcfcbc9890f49c65068db41b740c39..ce2f4d87d4714e2627d1e21830517ddb4be39bae 100644 (file)
@@ -134,7 +134,7 @@ Now let's do all that, but this time using the new, shiny `Relationship` attribu
 
 Now we can create the `Team` instances and pass them directly to the new `team` argument when creating the `Hero` instances, as `team=team_preventers` instead of `team_id=team_preventers.id`.
 
-And thanks to SQLAlchemy and how it works underneath, these teams don't even have to have an ID yet, but because we are assigning the whole object to each hero, those teams **will be automatically created** in the database, the automatic ID will be generated, and will be set in the `team_id` column for each of the corresponding hero rows.
+And thanks to SQLAlchemy and how it works underneath, these teams don't even need to have an ID yet, but because we are assigning the whole object to each hero, those teams **will be automatically created** in the database, the automatic ID will be generated, and will be set in the `team_id` column for each of the corresponding hero rows.
 
 In fact, now we don't even have to put the teams explicitly in the session with `session.add(team)`, because these `Team` instances are **already associated** with heroes that **we do** `add` to the session.
 
index 46306561b4bba1e424863c1e7554fcd513aef3a1..5bc3139b57e2cd57bd257a4dbe991d19df78fa38 100644 (file)
@@ -1250,7 +1250,7 @@ It would be an error telling you that
 
 > `Hero.age` is potentially `None`, and you cannot compare `None` with `>`
 
-This is because as we are using pure and plain Python annotations for the fields, `age` is indeed annotated as `Optional[int]`, which means `int` or `None`.
+This is because as we are using pure and plain Python annotations for the fields, `age` is indeed annotated as `int | None (or Optional[int])`.
 
 By using this simple and standard Python type annotations we get the benefit of the extra simplicity and the inline error checks when creating or using instances. ✨