✏️ Fix typos found with codespell

docs/tutorial/automatic-id-none-refresh.md

@@ -36,7 +36,7 @@ When we create a new `Hero` instance, we don't set the `id`:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-26]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -125,7 +125,7 @@ We can verify by creating a session using a `with` block and adding the objects.
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-41]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -238,7 +238,7 @@ To confirm and understand how this **automatic expiration and refresh** of data
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-58]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -271,7 +271,7 @@ Let's see how it works:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 // After committing, the objects are expired and have no values
 After committing the session
@@ -335,7 +335,7 @@ You can do that too with `session.refresh(object)`:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-67]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -362,7 +362,7 @@ Here's how the output would look like:
 ```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 
@@ -427,7 +427,7 @@ And the output shows again the same data:
 ```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

docs/tutorial/code-structure.md

@@ -168,7 +168,7 @@ Let's assume that now the file structure is:
 
 ### 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.
 

docs/tutorial/connect/create-connected-tables.md

@@ -106,7 +106,7 @@ This is the same model we have been using up to now, we are just adding the new
 
 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.
 

docs/tutorial/create-db-and-table-with-db-browser.md

@@ -164,6 +164,6 @@ Of course, you can also go and take a full SQL course or read a book about SQL,
 
 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. 🔍

docs/tutorial/fastapi/tests.md

@@ -82,7 +82,7 @@ But now, we need to deal with a bit of logistics and details we are not paying a
 
 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.
 

docs/tutorial/index.md

@@ -139,7 +139,7 @@ Here are the commands you could use:
     // 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
@@ -161,7 +161,7 @@ Here are the commands you could use:
     ```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

docs/tutorial/insert.md

@@ -171,7 +171,7 @@ The first step is to import the `Session` class:
 ```Python hl_lines="3"
 {!./docs_src/tutorial/insert/tutorial001.py[ln:1-3]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>

docs/tutorial/many-to-many/create-data.md

@@ -179,4 +179,4 @@ INFO Engine ROLLBACK
 
 ## 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. ✨

docs/tutorial/one.md

@@ -12,7 +12,7 @@ Let's see the utilities to read a single row.
 
 ## 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>

docs/tutorial/relationship-attributes/back-populates.md

@@ -123,7 +123,7 @@ Now let's update **Spider-Boy**, removing him from the team by setting `hero_spi
 
 </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**. 🔥
 

docs/tutorial/relationship-attributes/read-relationships.md

@@ -52,7 +52,7 @@ With what we have learned **up to now**, we could use a `select()` statement, th
 
 ## 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:
 

docs/tutorial/select.md

@@ -190,7 +190,7 @@ First we have to import `select` from `sqlmodel` at the top of the file:
 ```Python hl_lines="3"
 {!./docs_src/tutorial/select/tutorial001.py[ln:1-3]!}
 
-# More code below ommitted 👇
+# More code below omitted 👇
 ```
 
 <details>
@@ -472,7 +472,7 @@ SQLAlchemy's own `Session` has a method `session.execute()`. It doesn't have a `
 
 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. ✨
 

docs/tutorial/where.md

@@ -206,7 +206,7 @@ We care specially about the **select** statement:
 
 ## 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 👆
@@ -748,7 +748,7 @@ FROM hero
 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'
 

docs_src/tutorial/automatic_id_none_refresh/annotations/en/tutorial002.md

@@ -157,7 +157,7 @@
     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:
 

docs_src/tutorial/update/annotations/en/tutorial004.md

@@ -132,7 +132,7 @@
     !!! 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:
 

sqlmodel/default.py

@@ -6,7 +6,7 @@ class _DefaultPlaceholder:
     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):
@@ -27,6 +27,6 @@ def Default(value: _TDefaultType) -> _TDefaultType:
     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

tests/test_validation.py

@@ -7,7 +7,7 @@
 
 
 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.