A Django Model is a Python class that represents data stored in a relational database. By inheriting from django.db.models.Model, a class becomes a database-backed model: its fields describe stored values, and Django maps the class to a table. A row becomes a Model object, so application code can work with musicians, authors, or bands instead of hand-writing database queries. section 1.1.2 section 4.12
A Model is declarative and functional. Declaring fields tells Django what columns and value types a table needs; for example, CharField values map to Python strings and DateField values map to Python date objects. The inherited base class also supplies database behavior through the default query manager, .objects. section 4.4 section 4.12
Creating a Musician
The default manager creates rows with keyword arguments matching Model fields. Musician.objects.create(first_name="Steve", last_name="Vai", birth=date(1960, 6, 6)) inserts data and returns the corresponding Musician object. Required fields must be supplied; missing values may not fail until Django runs the database statement. Model instances can also be changed with .save() and removed with .delete(). section 4.4 section 4.12
(venv) RiffMates$ python manage.py shell Python 3.12.1 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from bands.models import Musician >>> from datetime import date >>> steve = Musician.objects.create(first_name="Steve", last_name="Vai", birth=date(1960, 6, 6)) #1
This shell session shows a Model imported from an app and used through its .objects manager to create a database-backed Musician instance. section 4.4
The .objects manager provides common database operations:
- .create(...) adds a row and returns a Model object. section 4.12
- .all(), .first(), and .last() retrieve matching Model objects. section 4.12
- .filter(...) retrieves a subset using field lookups, including comparisons such as first_name__startswith="J". section 4.12 section 1.1.2
- Query results are QuerySets, which can be passed to templates as context for generated HTML. section 1.1.2
The Python-object view is convenient, but a Model remains a proxy for database work. Design the resulting tables as carefully as the classes: separate student, teacher, and staff models can duplicate fields, while a flatter Person model with a role attribute can keep shared data together. Relationships also affect query cost, because fetching related objects can require additional database lookups. section 4.10
After changing Model definitions, makemigrations creates Python migration files describing database changes, and migrate applies those changes. Django uses SQLite by default, while the ORM abstraction can work across supported database backends without changing ordinary application code. section 4.12 section 1.1.2
