# Automatic IDs, None Defaults, and Refreshing Data
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)`:
Because we don't set the `id`, it takes the Python's default value of `None` that we set in `Field(default=None)`.
This is the only reason why we define it with `Optional` and with a default value of `None`.
Because at this point in the code, **before interacting with the database**, the Python value could actually be `None`.
If we assumed that the `id` was *always* an `int` and added the type annotation without `Optional`, we could end up writing broken code, like:
```Python
next_hero_id = hero_1.id + 1
```
If we ran this code before saving the hero to the database and the `hero_1.id` was still `None`, we would get an error like:
```
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
```
But by declaring it with `Optional[int]` the editor will help us to avoid writing broken code by showing us a warning telling us that the code could be invalid if `hero_1.id` is `None`. 🔍
## Print the Default `id` Values
We can confirm that by printing our heroes before adding them to the database:
As we saw before, the **session** is smart and doesn't talk to the database every time we prepare something to be changed, only after we are ready and tell it to `commit` the changes it goes and sends all the SQL to the database to store the data.
## Commit the Changes to the Database
Then we can `commit` the changes in the session, and print again:
And now, something unexpected happens, look at the output, it seems as if the `Hero` instance objects had no data at all:
<divclass="termy">
```console
$ python app.py
// Output above ommitted 👆
// Here the engine talks to the database, the SQL part
INFO Engine BEGIN (implicit)
INFO Engine INSERT INTO hero (name, secret_name, age) VALUES (?, ?, ?)
INFO Engine [generated in 0.00018s] ('Deadpond', 'Dive Wilson', None)
INFO Engine INSERT INTO hero (name, secret_name, age) VALUES (?, ?, ?)
INFO Engine [cached since 0.0008968s ago] ('Spider-Boy', 'Pedro Parqueador', None)
INFO Engine INSERT INTO hero (name, secret_name, age) VALUES (?, ?, ?)
INFO Engine [cached since 0.001143s ago] ('Rusty-Man', 'Tommy Sharp', 48)
INFO Engine COMMIT
// And now our prints
After committing the session
Hero 1:
Hero 2:
Hero 3:
// What is happening here? 😱
```
</div>
What happens is that SQLModel (actually SQLAlchemy) is internally marking those objects as "expired", they **don't have the latest version of their data**. This is because we could have some fields updated in the database, for example, imagine a field `updated_at: datetime` that was automatically updated when we saved changes.
The same way, other values could have changed, so the option the **session** has to be sure and safe is to just internally mark the objects as expired.
And then, next time we access each attribute, for example with:
```Python
current_hero_name = hero_1.name
```
...SQLModel (actually SQLAlchemy) will make sure to contact the database and **get the most recent version of the data**, updating that field `name` in our object and then making it available for the rest of the Python expression. In the example above, at that point, Python would be able to continue executing and use that `hero_1.name` value (just updated) to put it in the variable `current_hero_name`.
All this happens automatically and behind the scenes. ✨
And here's the funny and strange thing with our example:
```Python
print("Hero 1:", hero_1)
```
We didn't access the object's attributes, like `hero.name`. We only accessed the entire object and printed it, so **SQLAlchemy has no way of knowing** that we want to access this object's data.
## Print a Single Field
To confirm and understand how this **automatic expiration and refresh** of data when accessing attributes work, we can print some individual fields (instance attributes):
Now we are actually accessing the attributes, because instead of printing the whole object `hero_1`:
```Python
print("Hero 1:", hero_1)
```
...we are now printing the `id` attribute in `hero.id`:
```Python
print("Hero 1 ID:", hero_1.id)
```
By accessing the attribute, that **triggers** a lot of work done by SQLModel (actually SQLAlchemy) underneath to **refresh the data from the database**, set it in the object's `id` attribute, and make it available for the Python expression (in this case just to print it).
Let's see how it works:
<divclass="termy">
```console
$ python app.py
// Output above ommitted 👆
// After committing, the objects are expired and have no values
After committing the session
Hero 1:
Hero 2:
Hero 3:
// Now we will access an attribute like the ID, this is the first print
After committing the session, show IDs
// Notice that before printing the first ID, the Session makes the Engine go to the database to refresh the data 🤓
INFO Engine BEGIN (implicit)
INFO Engine SELECT hero.id AS hero_id, hero.name AS hero_name, hero.secret_name AS hero_secret_name, hero.age AS hero_age
FROM hero
WHERE hero.id = ?
INFO Engine [generated in 0.00017s] (1,)
// Here's our first print, now we have the database-generated ID
Hero 1 ID: 1
// Before the next print, refresh the data for the second object
INFO Engine SELECT hero.id AS hero_id, hero.name AS hero_name, hero.secret_name AS hero_secret_name, hero.age AS hero_age
FROM hero
WHERE hero.id = ?
INFO Engine [cached since 0.001245s ago] (2,)
// Here's our print for the second hero with its auto-generated ID
Hero 2 ID: 2
// Before the third print, refresh its data
INFO Engine SELECT hero.id AS hero_id, hero.name AS hero_name, hero.secret_name AS hero_secret_name, hero.age AS hero_age
FROM hero
WHERE hero.id = ?
INFO Engine [cached since 0.002215s ago] (3,)
// And here's our print for the third hero
Hero 3 ID: 3
// What if we print another attribute like the name?
After committing the session, show names
Hero 1 name: Deadpond
Hero 2 name: Spider-Boy
Hero 3 name: Rusty-Man
// Because the Session already refreshed these objects with all their data and the session knows they are not expired, it doesn't have to go again to the database for the names 🤓
```
</div>
## Refresh Objects Explicitly
You just learnt how the **session** refreshes the data automatically behind the scenes, as a side effect, when you access an attribute.
But what if you want to **explicitly refresh** the data?
You can do that too with `session.refresh(object)`:
...the **session** goes and makes the **engine** communicate with the database to get the recent data for this object `hero_1`, and then the **session** puts the data in the `hero_1` object and marks it as "fresh" or "not expired".
Here's how the output would look like:
<divclass="termy">
```console
$ python app.py
// Output above ommitted 👆
// The first refresh
INFO Engine SELECT hero.id, hero.name, hero.secret_name, hero.age
FROM hero
WHERE hero.id = ?
INFO Engine [generated in 0.00024s] (1,)
// The second refresh
INFO Engine SELECT hero.id, hero.name, hero.secret_name, hero.age
FROM hero
WHERE hero.id = ?
INFO Engine [cached since 0.001487s ago] (2,)
// The third refresh
INFO Engine SELECT hero.id, hero.name, hero.secret_name, hero.age
FROM hero
WHERE hero.id = ?
INFO Engine [cached since 0.002377s ago] (3,)
// Now print the data, as it's already refreshed there's no need for the Session to go and refresh it again
This could be useful, for example, if you are building a web API to create heroes. And once a hero is created with some data, you return it to the client.
You wouldn't want to return an object that looks empty because the automatic magic to refresh the data was not triggered.
In this case, after committing the object to the database with the **session**, you could refresh it, and then return it to the client. This would ensure that the object has its fresh data.
// 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
You read all that! That was a lot! Have some cake, you earned it. 🍰
We discussed how the **session** uses the **engine** to send SQL to the database, to create data and to fetch data too. How it keeps track of "**expired**" and "**fresh**" data. At which moments it **fetches data automatically** (when accessing instance attributes) and how that data is synchronized between objects in memory and the database via the **session**.
If you understood all that, now you know a lot about **SQLModel**, SQLAlchemy, and how the interactions from Python with databases work in general.
If you didn't get all that, it's fine, you can always come back later to <abbrtitle="See what I did there? 😜">`refresh`</abbr> the concepts.
I think this might be one of the main types of bugs that cause problems and makes you scratch your head. So, good job studying it! 💪
