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

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

\n

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

\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 configuration uses SQLite. If you’re new to databases, or\nyou’re just interested in trying Django, this is the easiest choice. SQLite is\nincluded in Python, so you won’t need to install anything else to support your\ndatabase. When starting your first real project, however, you may want to use a\nmore scalable database like PostgreSQL, to avoid database-switching headaches\ndown the road.

\n

If you wish to use another database, install the appropriate database\nbindings and change the following keys in the\nDATABASES 'default' item to match your database connection\nsettings:

\n\n

If you are not using SQLite as your database, additional settings such as\nUSER, PASSWORD, and HOST must be added.\nFor more details, see the reference documentation for DATABASES.

\n\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
Shell
$ python 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; (MySQL), .schema\n(SQLite), or SELECT TABLE_NAME FROM USER_TABLES; (Oracle) to display the\ntables 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 simple poll app, we’ll create two models: Question and Choice.\nA Question 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 simple Python classes. Edit the\npolls/models.py file so it looks like this:

\n
polls/models.py
Code
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

The code is straightforward. Each model is represented by a class that\nsubclasses django.db.models.Model. Each model has a number of class\nvariables, each 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
Code
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
Shell
$ python 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 Choice\n    - Create model Question\n    - Add field question to 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 just files on disk. You can read the migration\nfor your new model if you like; it’s the file\npolls/migrations/0001_initial.py. Don’t worry, you’re not expected to read\nthem every time Django makes one, but they’re designed to be human-editable\nin case you want to manually tweak how Django 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
Shell
$ python 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 Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL\n);\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Add field question to choice\n--\nALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;\nALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;\nCREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\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
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

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\nuseable 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
Shell
$ python 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 Django\nthe Python import path to your mysite/settings.py file.

\n\n

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

\n
Code
>>> from polls.models import Question, Choice   # Import the model classes we just wrote.\n\n# 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. Note that this might say "1L" instead of "1", depending\n# on which database you're using. That's no biggie; it just means your\n# database backend prefers to return integers as Python long integer\n# objects.\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=<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>]>\n
\n

Wait a minute. <Question: Question object> is, utterly, an unhelpful representation\nof this object. Let’s fix that by editing the Question model (in the\npolls/models.py file) and adding a\n__str__() method to both Question and\nChoice:

\n
polls/models.py
Code
from django.db import models\nfrom django.utils.encoding import python_2_unicode_compatible\n\n@python_2_unicode_compatible  # only if you need to support Python 2\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\n@python_2_unicode_compatible  # only if you need to support Python 2\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

Note these are normal Python methods. Let’s add a custom method, just for\ndemonstration:

\n
polls/models.py
Code
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 by running\npython manage.py shell again:

\n
Code
>>> from polls.models import Question, Choice\n\n# 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 to hold the "other side" of a ForeignKey relation\n# (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
Shell
$ python 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
Shell
$ python 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,\nthe login screen may be displayed in your own language, depending on your\nbrowser’s settings and if Django has a translation for this language.

\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

Just one thing to do: we need to tell the admin that Question\nobjects have an admin interface. To do this, open the polls/admin.py\nfile, and edit it to look like this:

\n
polls/admin.py
Code
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/1.11/intro/"}],"prev":{"docname":"intro/tutorial01","title":"Writing your first Django app, part 1","url":"/en/1.11/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"Writing your first Django app, part 3","url":"/en/1.11/intro/tutorial03/"},"formats":{"html":"/en/1.11/intro/tutorial02/","markdown":"/en/1.11/intro/tutorial02.md","json":"/en/1.11/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/1.11.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/en/1.11/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","fr","ja","id","pt-br","ko","es","el","pl"]}