Models & ORM

Writing raw SQL queries (SELECT * FROM users) is incredibly dangerous and tedious. It exposes you to catastrophic SQL Injection attacks and locks your codebase to a single database dialect (like PostgreSQL).

Django's ORM solves this by acting as a universal translator. You write standard Python code (Article.objects.all()), and the ORM translates that into highly-optimized, secure SQL behind the scenes. This means you can build your MVP using a lightweight SQLite database, and later switch your production server to a massive PostgreSQL cluster simply by changing one line in settings.py. You never rewrite a single query.

The biggest mistake junior developers make is editing a models.py file and wondering why the website crashed. The database is a completely separate entity from your Python code; it does not magically update itself.

You must master the two-step sync process:

1. `makemigrations`: This is the Architect. It scans your Python code, detects changes, and writes a strict blueprint (a migration file) detailing exactly how the database structure needs to change.

2. `migrate`: This is the Builder. It takes the blueprint generated above and physically executes the SQL ALTER TABLE commands against the live database.

Django models aggressively protect your database from garbage data. The database layer is the last line of defense.

If you define a models.EmailField(), Django will strictly reject any string that isn't a valid email format before it ever hits PostgreSQL. If you use an models.IntegerField(), it violently rejects text. By strictly typing your model fields, utilizing max_length, and strategically using constraints, you guarantee that the data persisted in your database is perfectly pristine, predictable, and safe.

The ORM Layer. Manually writing raw SQL queries (SELECT * FROM users WHERE...) is incredibly tedious, highly prone to syntax errors, and creates severe security risks like SQL Injection. Django completely solves this with its Object-Relational Mapper (ORM). The ORM allows you to define your database structure using simple Python Classes, and it automatically translates your Python code into highly optimized SQL commands behind the scenes.

Database Fields. Inside a Model, each Python attribute explicitly represents a specific Column in the database table. Django requires you to declare the exact data type using Field classes. For short text (like titles), you strictly use CharField and define a maximum length. For massive blocks of text (like blog posts), you use TextField. This forces data integrity at the database level.

Which Django model field would you use to store a massive, 10,000-word blog post?

• →models.CharField(max_length=10000)
• →models.TextField()

makemigrations. Whenever you create a new Model or modify an existing one, the database has absolutely no idea that your Python code changed. You must first run makemigrations. This critical command acts as a 'detective'. It aggressively scans your models.py files, spots the differences, and generates a 'Migration File'. Think of a migration file as a strict set of blueprints or instructions detailing exactly how the database structure needs to change.

migrate. While makemigrations creates the blueprints, it does absolutely nothing to the actual database. To execute those instructions and physically alter the database tables, you must run the migrate command. Django will systematically read the migration files and execute the required SQL commands (like CREATE TABLE or ALTER TABLE) directly against your configured PostgreSQL or SQLite instance.

You just added a new price field to your Product model. What are the EXACT two commands you must run in the terminal, in order, to update the actual database?

• →python manage.py migrate
• →1. python manage.py makemigrations

2. python manage.py migrate

The __str__ Method. When you print a Django model object, Python defaults to displaying an ugly, unhelpful string like <Article: Article object (1)>. This makes debugging in the terminal or using the Django Admin panel a completely miserable experience. You must forcefully override the magical __str__ method on your Model class to return a human-readable string, strictly defining how the object should represent itself.

Model Options (Meta). Sometimes you need to configure database-level behaviors that don't belong to a specific field. For example, you might want to force the database to always return records ordered by their creation date, or change the plural name displayed in the Django Admin. You accomplish this by declaring an internal Meta class inside your Model. This is where all configuration data 'about' the model lives.

If you want the Django Admin panel to display 'Stories' instead of 'Storys' for a model named Story, where would you define the verbose_name_plural attribute?

• →Inside the internal class Meta: block of the model.
• →Inside settings.py

Database Models Architected. Outstanding! You now possess a deep understanding of the Django Object-Relational Mapper (ORM). You have mastered defining SQL structures using Python classes, executing the critical two-step Migration process, and refining the model's behavior using __str__ and the Meta class. In the next module, we will unlock the true power of relational databases by connecting Models together using Relationships.