{"title":"Writing your first Django app, part 2","version":"5.2","locale":"en","docname":"intro/tutorial02","url":"/en/5.2/intro/tutorial02/","canonical":"https://djangodocs.dev/en/5.2/intro/tutorial02/","summary":"This tutorial begins where Tutorial 1 left off. We’ll set up the database, create your first model, and get a quick introduction to Django’s…","html":"

Writing your first Django app, part 2Link to this heading#

\n

This tutorial begins where Tutorial 1 left off.\nWe’ll set up the database, create your first model, and get a quick\nintroduction to Django’s automatically-generated admin site.

\n\n
\n

Database setupLink to this heading#

\n

Now, open up mysite/settings.py. It’s a normal Python module with\nmodule-level variables representing Django settings.

\n

By default, the DATABASES configuration uses SQLite. If you’re new\nto databases, or you’re just interested in trying Django, this is the easiest\nchoice. SQLite is included in Python, so you won’t need to install anything\nelse to support your database. When starting your first real project, however,\nyou may want to use a more scalable database like PostgreSQL, to avoid\ndatabase-switching headaches down the road.

\n

If you wish to use another database, see details to customize and get\nyour database running.

\n

While you’re editing mysite/settings.py, set TIME_ZONE to\nyour time zone.

\n

Also, note the INSTALLED_APPS setting at the top of the file. That\nholds the names of all Django applications that are activated in this Django\ninstance. Apps can be used in multiple projects, and you can package and\ndistribute them for use by others in their projects.

\n

By default, INSTALLED_APPS contains the following apps, all of which\ncome with Django:

\n\n

These applications are included by default as a convenience for the common case.

\n

Some of these applications make use of at least one database table, though,\nso we need to create the tables in the database before we can use them. To do\nthat, run the following command:

\n

Linux / macOS

Shell
$ python manage.py migrate\n
\n

Windows

Windows
...\\> py manage.py migrate\n
\n

The migrate command looks at the INSTALLED_APPS setting\nand creates any necessary database tables according to the database settings\nin your mysite/settings.py file and the database migrations shipped\nwith the app (we’ll cover those later). You’ll see a message for each\nmigration it applies. If you’re interested, run the command-line client for your\ndatabase and type \\dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL),\n.tables (SQLite), or SELECT TABLE_NAME FROM USER_TABLES; (Oracle) to\ndisplay the tables Django created.

\n\n
\n
\n

Creating modelsLink to this heading#

\n

Now we’ll define your models – essentially, your database layout, with\nadditional metadata.

\n\n

In our poll app, we’ll create two models: Question and Choice. A\nQuestion has a question and a publication date. A Choice has two\nfields: the text of the choice and a vote tally. Each Choice is associated\nwith a Question.

\n

These concepts are represented by Python classes. Edit the\npolls/models.py file so it looks like this:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    question_text = models.CharField(max_length=200)\n    pub_date = models.DateTimeField("date published")\n\n\nclass Choice(models.Model):\n    question = models.ForeignKey(Question, on_delete=models.CASCADE)\n    choice_text = models.CharField(max_length=200)\n    votes = models.IntegerField(default=0)\n
\n

Here, each model is represented by a class that subclasses\ndjango.db.models.Model. Each model has a number of class variables,\neach of which represents a database field in the model.

\n

Each field is represented by an instance of a Field\nclass – e.g., CharField for character fields and\nDateTimeField for datetimes. This tells Django what\ntype of data each field holds.

\n

The name of each Field instance (e.g.\nquestion_text or pub_date) is the field’s name, in machine-friendly\nformat. You’ll use this value in your Python code, and your database will use\nit as the column name.

\n

You can use an optional first positional argument to a\nField to designate a human-readable name. That’s used\nin a couple of introspective parts of Django, and it doubles as documentation.\nIf this field isn’t provided, Django will use the machine-readable name. In this\nexample, we’ve only defined a human-readable name for Question.pub_date.\nFor all other fields in this model, the field’s machine-readable name will\nsuffice as its human-readable name.

\n

Some Field classes have required arguments.\nCharField, for example, requires that you give it a\nmax_length. That’s used not only in the\ndatabase schema, but in validation, as we’ll soon see.

\n

A Field can also have various optional arguments; in\nthis case, we’ve set the default value of\nvotes to 0.

\n

Finally, note a relationship is defined, using\nForeignKey. That tells Django each Choice is\nrelated to a single Question. Django supports all the common database\nrelationships: many-to-one, many-to-many, and one-to-one.

\n
\n
\n

Activating modelsLink to this heading#

\n

That small bit of model code gives Django a lot of information. With it, Django\nis able to:

\n\n

But first we need to tell our project that the polls app is installed.

\n\n

To include the app in our project, we need to add a reference to its\nconfiguration class in the INSTALLED_APPS setting. The\nPollsConfig class is in the polls/apps.py file, so its dotted path\nis 'polls.apps.PollsConfig'. Edit the mysite/settings.py file and\nadd that dotted path to the INSTALLED_APPS setting. It’ll look like\nthis:

\n
mysite/settings.py
\n
Python
INSTALLED_APPS = [\n    "polls.apps.PollsConfig",\n    "django.contrib.admin",\n    "django.contrib.auth",\n    "django.contrib.contenttypes",\n    "django.contrib.sessions",\n    "django.contrib.messages",\n    "django.contrib.staticfiles",\n]\n
\n

Now Django knows to include the polls app. Let’s run another command:

\n

Linux / macOS

Shell
$ python manage.py makemigrations polls\n
\n

Windows

Windows
...\\> py manage.py makemigrations polls\n
\n

You should see something similar to the following:

\n
Text
Migrations for 'polls':\n  polls/migrations/0001_initial.py\n    + Create model Question\n    + Create model Choice\n
\n

By running makemigrations, you’re telling Django that you’ve made\nsome changes to your models (in this case, you’ve made new ones) and that\nyou’d like the changes to be stored as a migration.

\n

Migrations are how Django stores changes to your models (and thus your\ndatabase schema) - they’re files on disk. You can read the migration for your\nnew model if you like; it’s the file polls/migrations/0001_initial.py.\nDon’t worry, you’re not expected to read them every time Django makes one, but\nthey’re designed to be human-editable in case you want to manually tweak how\nDjango changes things.

\n

There’s a command that will run the migrations for you and manage your database\nschema automatically - that’s called migrate, and we’ll come to it in a\nmoment - but first, let’s see what SQL that migration would run. The\nsqlmigrate command takes migration names and returns their SQL:

\n

Linux / macOS

Shell
$ python manage.py sqlmigrate polls 0001\n
\n

Windows

Windows
...\\> py manage.py sqlmigrate polls 0001\n
\n

You should see something similar to the following (we’ve reformatted it for\nreadability):

\n
SQL
BEGIN;\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Create model Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL,\n    "question_id" bigint NOT NULL\n);\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\nCREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");\n\nCOMMIT;\n
\n

Note the following:

\n\n

If you’re interested, you can also run\npython manage.py check; this checks for any problems in\nyour project without making migrations or touching the database.

\n

Now, run migrate again to create those model tables in your database:

\n

Linux / macOS

Shell
$ python manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Rendering model states... DONE\n  Applying polls.0001_initial... OK\n
\n

Windows

Windows
...\\> py manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Rendering model states... DONE\n  Applying polls.0001_initial... OK\n
\n

The migrate command takes all the migrations that haven’t been\napplied (Django tracks which ones are applied using a special table in your\ndatabase called django_migrations) and runs them against your database -\nessentially, synchronizing the changes you made to your models with the schema\nin the database.

\n

Migrations are very powerful and let you change your models over time, as you\ndevelop your project, without the need to delete your database or tables and\nmake new ones - it specializes in upgrading your database live, without\nlosing data. We’ll cover them in more depth in a later part of the tutorial,\nbut for now, remember the three-step guide to making model changes:

\n\n

The reason that there are separate commands to make and apply migrations is\nbecause you’ll commit migrations to your version control system and ship them\nwith your app; they not only make your development easier, they’re also\nusable by other developers and in production.

\n

Read the django-admin documentation for full\ninformation on what the manage.py utility can do.

\n
\n
\n

Playing with the APILink to this heading#

\n

Now, let’s hop into the interactive Python shell and play around with the free\nAPI Django gives you. To invoke the Python shell, use this command:

\n

Linux / macOS

Shell
$ python manage.py shell\n
\n

Windows

Windows
...\\> py manage.py shell\n
\n

We’re using this instead of simply typing “python”, because manage.py\nsets the DJANGO_SETTINGS_MODULE environment variable, which gives\nDjango the Python import path to your mysite/settings.py file.\nBy default, the shell command automatically imports the models from\nyour INSTALLED_APPS.

\n

Once you’re in the shell, explore the database API:

\n
Python console
# No questions are in the system yet.\n>>> Question.objects.all()\n<QuerySet []>\n\n# Create a new Question.\n# Support for time zones is enabled in the default settings file, so\n# Django expects a datetime with tzinfo for pub_date. Use timezone.now()\n# instead of datetime.datetime.now() and it will do the right thing.\n>>> from django.utils import timezone\n>>> q = Question(question_text="What's new?", pub_date=timezone.now())\n\n# Save the object into the database. You have to call save() explicitly.\n>>> q.save()\n\n# Now it has an ID.\n>>> q.id\n1\n\n# Access model field values via Python attributes.\n>>> q.question_text\n"What's new?"\n>>> q.pub_date\ndatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.timezone.utc)\n\n# Change values by changing the attributes, then calling save().\n>>> q.question_text = "What's up?"\n>>> q.save()\n\n# objects.all() displays all the questions in the database.\n>>> Question.objects.all()\n<QuerySet [<Question: Question object (1)>]>\n
\n

Wait a minute. <Question: Question object (1)> isn’t a helpful\nrepresentation of this object. Let’s fix that by editing the Question model\n(in the polls/models.py file) and adding a\n__str__() method to both Question and\nChoice:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\n\nclass Choice(models.Model):\n    # ...\n    def __str__(self):\n        return self.choice_text\n
\n

It’s important to add __str__() methods to your\nmodels, not only for your own convenience when dealing with the interactive\nprompt, but also because objects’ representations are used throughout Django’s\nautomatically-generated admin.

\n

Let’s also add a custom method to this model:

\n
polls/models.py
\n
Python
import datetime\n\nfrom django.db import models\nfrom django.utils import timezone\n\n\nclass Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)\n
\n

Note the addition of import datetime and from django.utils import\ntimezone, to reference Python’s standard datetime module and Django’s\ntime-zone-related utilities in django.utils.timezone, respectively. If\nyou aren’t familiar with time zone handling in Python, you can learn more in\nthe time zone support docs.

\n

Save these changes and start a new Python interactive shell. (If a\nthree-chevron prompt (>>>) indicates you are still in the shell, you need to\nexit first using exit()). Run python manage.py shell again to reload\nthe models.

\n
Python console
# Make sure our __str__() addition worked.\n>>> Question.objects.all()\n<QuerySet [<Question: What's up?>]>\n\n# Django provides a rich database lookup API that's entirely driven by\n# keyword arguments.\n>>> Question.objects.filter(id=1)\n<QuerySet [<Question: What's up?>]>\n>>> Question.objects.filter(question_text__startswith="What")\n<QuerySet [<Question: What's up?>]>\n\n# Get the question that was published this year.\n>>> from django.utils import timezone\n>>> current_year = timezone.now().year\n>>> Question.objects.get(pub_date__year=current_year)\n<Question: What's up?>\n\n# Request an ID that doesn't exist, this will raise an exception.\n>>> Question.objects.get(id=2)\nTraceback (most recent call last):\n    ...\nDoesNotExist: Question matching query does not exist.\n\n# Lookup by a primary key is the most common case, so Django provides a\n# shortcut for primary-key exact lookups.\n# The following is identical to Question.objects.get(id=1).\n>>> Question.objects.get(pk=1)\n<Question: What's up?>\n\n# Make sure our custom method worked.\n>>> q = Question.objects.get(pk=1)\n>>> q.was_published_recently()\nTrue\n\n# Give the Question a couple of Choices. The create call constructs a new\n# Choice object, does the INSERT statement, adds the choice to the set\n# of available choices and returns the new Choice object. Django creates\n# a set (defined as "choice_set") to hold the "other side" of a ForeignKey\n# relation (e.g. a question's choice) which can be accessed via the API.\n>>> q = Question.objects.get(pk=1)\n\n# Display any choices from the related object set -- none so far.\n>>> q.choice_set.all()\n<QuerySet []>\n\n# Create three choices.\n>>> q.choice_set.create(choice_text="Not much", votes=0)\n<Choice: Not much>\n>>> q.choice_set.create(choice_text="The sky", votes=0)\n<Choice: The sky>\n>>> c = q.choice_set.create(choice_text="Just hacking again", votes=0)\n\n# Choice objects have API access to their related Question objects.\n>>> c.question\n<Question: What's up?>\n\n# And vice versa: Question objects get access to Choice objects.\n>>> q.choice_set.all()\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n>>> q.choice_set.count()\n3\n\n# The API automatically follows relationships as far as you need.\n# Use double underscores to separate relationships.\n# This works as many levels deep as you want; there's no limit.\n# Find all Choices for any question whose pub_date is in this year\n# (reusing the 'current_year' variable we created above).\n>>> Choice.objects.filter(question__pub_date__year=current_year)\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n\n# Let's delete one of the choices. Use delete() for that.\n>>> c = q.choice_set.filter(choice_text__startswith="Just hacking")\n>>> c.delete()\n
\n

For more information on model relations, see Accessing related objects. For more on how to use double underscores to perform\nfield lookups via the API, see Field lookups. For\nfull details on the database API, see our Database API reference.

\n
\n
\n

Introducing the Django AdminLink to this heading#

\n\n
\n

Creating an admin userLink to this heading#

\n

First we’ll need to create a user who can login to the admin site. Run the\nfollowing command:

\n

Linux / macOS

Shell
$ python manage.py createsuperuser\n
\n

Windows

Windows
...\\> py manage.py createsuperuser\n
\n

Enter your desired username and press enter.

\n
Text
Username: admin\n
\n

You will then be prompted for your desired email address:

\n
Text
Email address: admin@example.com\n
\n

The final step is to enter your password. You will be asked to enter your\npassword twice, the second time as a confirmation of the first.

\n
Text
Password: **********\nPassword (again): *********\nSuperuser created successfully.\n
\n
\n
\n

Start the development serverLink to this heading#

\n

The Django admin site is activated by default. Let’s start the development\nserver and explore it.

\n

If the server is not running start it like so:

\n

Linux / macOS

Shell
$ python manage.py runserver\n
\n

Windows

Windows
...\\> py manage.py runserver\n
\n

Now, open a web browser and go to “/admin/” on your local domain – e.g.,\nhttp://127.0.0.1:8000/admin/. You should see the admin’s login screen:

\n\"Django\n

Since translation is turned on by default, if\nyou set LANGUAGE_CODE, the login screen will be displayed in the\ngiven language (if Django has appropriate translations).

\n
\n
\n

Enter the admin siteLink to this heading#

\n

Now, try logging in with the superuser account you created in the previous step.\nYou should see the Django admin index page:

\n\"Django\n

You should see a few types of editable content: groups and users. They are\nprovided by django.contrib.auth, the authentication framework shipped\nby Django.

\n
\n
\n

Make the poll app modifiable in the adminLink to this heading#

\n

But where’s our poll app? It’s not displayed on the admin index page.

\n

Only one more thing to do: we need to tell the admin that Question objects\nhave an admin interface. To do this, open the polls/admin.py file, and\nedit it to look like this:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\nadmin.site.register(Question)\n
\n
\n
\n

Explore the free admin functionalityLink to this heading#

\n

Now that we’ve registered Question, Django knows that it should be displayed on\nthe admin index page:

\n\"Django\n

Click “Questions”. Now you’re at the “change list” page for questions. This page\ndisplays all the questions in the database and lets you choose one to change it.\nThere’s the “What’s up?” question we created earlier:

\n\"Polls\n

Click the “What’s up?” question to edit it:

\n\"Editing\n

Things to note here:

\n\n

The bottom part of the page gives you a couple of options:

\n\n

If the value of “Date published” doesn’t match the time when you created the\nquestion in Tutorial 1, it probably\nmeans you forgot to set the correct value for the TIME_ZONE setting.\nChange it, reload the page and check that the correct value appears.

\n

Change the “Date published” by clicking the “Today” and “Now” shortcuts. Then\nclick “Save and continue editing.” Then click “History” in the upper right.\nYou’ll see a page listing all changes made to this object via the Django admin,\nwith the timestamp and username of the person who made the change:

\n\"History\n

When you’re comfortable with the models API and have familiarized yourself with\nthe admin site, read part 3 of this tutorial to learn\nabout how to add more views to our polls app.

\n
\n
","rootId":"writing-your-first-django-app-part-2","toc":[{"title":"Database setup","anchor":"database-setup","children":[]},{"title":"Creating models","anchor":"creating-models","children":[]},{"title":"Activating models","anchor":"activating-models","children":[]},{"title":"Playing with the API","anchor":"playing-with-the-api","children":[]},{"title":"Introducing the Django Admin","anchor":"introducing-the-django-admin","children":[{"title":"Creating an admin user","anchor":"creating-an-admin-user","children":[]},{"title":"Start the development server","anchor":"start-the-development-server","children":[]},{"title":"Enter the admin site","anchor":"enter-the-admin-site","children":[]},{"title":"Make the poll app modifiable in the admin","anchor":"make-the-poll-app-modifiable-in-the-admin","children":[]},{"title":"Explore the free admin functionality","anchor":"explore-the-free-admin-functionality","children":[]}]}],"breadcrumbs":[{"docname":"intro/index","title":"Getting started","url":"/en/5.2/intro/"}],"prev":{"docname":"intro/tutorial01","title":"Writing your first Django app, part 1","url":"/en/5.2/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"Writing your first Django app, part 3","url":"/en/5.2/intro/tutorial03/"},"formats":{"html":"/en/5.2/intro/tutorial02/","markdown":"/en/5.2/intro/tutorial02.md","json":"/en/5.2/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/5.2.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/en/5.2/intro/tutorial02/","inVersions":["dev","6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9","1.8"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}